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FACILITATING ELECTRONIC COMMERCE MARKETPLACES 
BY AUTOMATICALLY GENERATING FILES 
FROM A STRUCTURAL ONTOLOGY SPECIFICATION 

RELATED APPLICATIONS 

The present application claims priority to, and incorporates by reference, the following 
United States provisional applications: serial no. 60/274,595 filed March 10, 2001, serial no. 
60/278,558 filed March 23, 2001, and serial no. 60/280,196 filed March 30, 2001. 

COPYRIGHT NOTICE 

A portion of the disclosure of this patent document contains material which is subject to 
copyright protection. The copyright owner has no objection to the facsimile reproduction by 
anyone of the patent document or the patent disclosure, as it appears in the Patent and 
Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever. 
The copyright owner does not hereby waive any of its rights to have thispatent document 
maintained in secrecy, including without limitation its rights pursuant to 37 C.F.R. § 1. 14. 

FIELD OF THE INVENTION 

The present invention relates generally to the creation and maintenance of computer 
network sites, and relates more particularly to tools and techniques for automatically 
generating files that are used in configuring commercial web sites. 

TECHNICAL BACKGROUND OF THE INVENTION 

Various approaches for generating commercial web sites are known. For instance, 
Figure 1 illustrates a prior approach like that discussed in the document titled "Welcome to 
eCommerce Tools!", which was provided at pages 20 through 48 of incorporated provisional 
application serial no. 60/274,595 filed March 10, 2001. The material described in said 
eCommerce Tools document is not, in and of itself, claimed as the present invention, but the 
eCommerce Tools document is part of the present application for purposes such as under- 
standing the state of the art. The catalog 100 is assumed to be a conventional catalog such as a 
paper catalog; it may also be in electronic form, such as in word processor files. A structural 
ontology of the web site 108, tools 104 used to generate the site 108, manual data entry 102, 
and automatic file generation 106 are discussed in particular at the eCommerce Tools 
document's internal pages 18-28. Apparently the structural ontology of the web site 108 exists 
as a whole only implicitly in the internal code and data structures of the eCommerce Tools 

1 
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software. There is apparently no express structural ontology specification which is human- 
readable by non-programmers, and which is easily copied (and possibly modified) for use in 
configuring several (possibly somewhat different) web marketplaces at about the same time. 
The focus of the approach shown in Figure 1 is instead on a single web site for a single vendor. 

Figure 2 illustrates an approach such as the approach that is discussed in the document 
titled "Chemdex™, a vortex business", which was provided at pages 49 through 51 of 
incorporated provisional application serial no. 60/274,595 filed March 10, 2001. The material 
described in said Chemdex™ document is not, in and of itself, claimed as the present 
invention, but the Chemdex™ document is part of the present application for purposes such as 
understanding the state of the art In this approach several vendors* catalogs 200-204 are 
integrated into a shared structural ontology 206 through a process 212 that generally involves 
negotiations between the parties to reach agreement on the details of the shared structural 
ontology 206, as well as automatic and manual extraction of product data and entry thereof into 
a product database. Tools 208 are used to generate HTML pages, and graphical data entry tools 
208 may be used to automatically populate a product database. The structural ontology 206 is 
apparently implicit in the code and internally used data of such a tool 208, rather than being an 
express structural ontology specification which is human-readable by non-programmers and 
which is easily used in several (possibly somewhat different) online marketplaces at the same 
time. The focus of the approach shown in Figure 2 is thus on a single marketplace, such as one 
for a particular industry; for instance, the Chemdex™ web site focused on commerce in 
products used for life sciences research. 

Figure 3 illustrates an architecture involving transactional ontologies, to help clarify the 
important difference between a transactional ontology and a structural ontology. As indicated, 
a transactional ontology is concerned with the data formats and procedures used to perform 
transactions between parties in a marketplace. Early transactional ontologies often involved 
Electronic Data Interchange (EDI) format specifications. More recently, extended Markup 
Language (XML) Document Type Definitions (DTD) and other XML or XML-related format 
specifications are being used to implement transactions in accordance with an agreed-upon 
transactional ontology. By contrast, a structural ontology is concerned primarily with the 
products being offered, with their attributes, and with their relations to one another through 
grouping into categories, for instance. That is, transactional ontology focuses on commercial 
transaction procedures such as how products are ordered and paid for, while structural 
ontology focuses on web site structures such as those that specify which product information is 
presented to potential buyers, and how products relate to each other. 
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Ventro Corporation, assignee of the present invention, assisted with and ultimately 
owned assets of, Promedix.com, Inc. Promedix.com operated a web marketplace generally 
resembling the Chemdex™ web site discussed above. In particular, Ventro Corporation is 
assignee of United States application serial no. 09/496,361 filed February 1, 2000 for 
5 Promedix.com Corporation, an application which discusses transactions in a hub & spoke 
architecture and which is incorporated herein as background to provide additional detail 
regarding systems that generally resemble the system of Figure 3. Figure 3 shows "prior art" 
with respect to the invention of the present application; statements made here regarding Figure 
3 and/or transactional systems and methods are meant to be understood in the context of this 

10 present application, not in any other application. 

Prior to the earliest priority date claimed above, Ventro Corporation has provided 
services to help build various marketplaces, including for example web sites operated by 
Amphire Solutions, Broadlane, Chemdex, Industria Solutions, MarketMile, and Promedix.com 
(marks of their respective owners). Spreadsheet files which are similar or identical in form to 

1 5 express structural ontology specifications 406 discussed below were known to at least inventor 
Ms. Shaffer prior to the earliest priority date claimed above. Such spreadsheet files, which 
were also known as "templates", were used by Ventro Corporation at least as early as August 
25, 1999 and may have been disclosed outside Ventro at least as early as February 29, 2000. 
However, they were not then used as a basis for scripts to operate on to generate engineering 

20 configuration files as called for by the present invention. In particular, Figure 8 of incorporated 
provisional application no. 60/274,595 shows a printout of a spreadsheet which is in a format 
closely resembling that of an early version of the ontology specification 406. This spreadsheet 
was created on or about August 25, 1999. It was apparently only used internally by Ventro 
Corporation and was not used as input to scripts for automatically generating 506 engineering 

25 configuration files. 

References which mention or discuss tools and techniques for facilitating electronic 
commerce are identified and discussed relative to the present invention in a Petition for Special 
Examining Procedure filed concurrently with the present application (or a U.S. counterpart). 
To the extent that the Petition describes the technical background of the invention, it is 

30 incorporated here by this reference. 

Building a marketplace may be a complex project drawing on the different abilities of 
many people. Prior to the present invention, a variety of problems arose. Because configuration 
files were generated by hand and different people participated in different marketplace 
projects, it was sometimes difficult to determine who was responsible for providing particular 
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configuration files. Manually converting data (even from a generally agreed-upon specifica- 
tion) into engineering configuration files was also a tedious process, and thus subject to errors 
and inconsistencies. Version control was difficult, and version inconsistencies were sometimes 
difficult to detect As a result, changes to a marketplace's ontology were sometimes avoided 
because of the implementation difficulties and risks they posed, even if the changes would 
improve the marketplace once they were properly implemented. 

Accordingly, it would be an advancement to provide tools and techniques to reduce 
such problems by improving the ease and consistency with which marketplace configuration 
files are generated. 

BRIEF SUMMARY OF THE INVENTION 

The present invention provides tools and techniques for facilitating electronic 
commerce by improving the ease and consistency with which marketplace configuration files 
are generated. The invention may be embodied in methods, in properly configured computer 
systems, and in properly configured computer storage media such as CD-ROMs or hard disks. 
The embodiments use or comprise an express structural ontology specification for an electronic 
commerce marketplace. The structural ontology specification is organized in a predefined 
format so that it can be parsed by a computer. It is an express and hence human-readable 
specification rather than being merely implicit in computer program code, and it preferably 
expressly specifies at least product categories, product generic attributes, and product category 
attributes. 

A method according to the invention automatically parses the structural ontology 
specification using a computerized tool. The tools is general purpose in that it is also capable 
of parsing other structural ontology specifications written in the predefined format; these may 
specify the ontology of other marketplaces and/or the ontology of different versions of the 
marketplace of interest The method extracts ontology information from the structural ontology 
specification using a computerized tool which can also extract ontology information from other 
structural ontology specifications. The method uses ontology information extracted from the 
structural ontology specification to automatically generate for the electronic commerce 
marketplace configuration materials, at least some of which configuration materials are not 
product catalog files. Inventive systems and configured storage media similarly use ontology 
information extracted from an express structural ontology specification to automatically 
generate configuration materials for an electronic commerce marketplace. 
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In some embodiments, the structural ontology specification expressly specifies one or 
more of: a data type for at least one attribute; a data size for at least one attribute; allowed data 
values for at least one attribute; a search type for at least one attribute; at least one mandatory 
attribute; at least one optional attribute; and a mapping between an attribute and a product 
5 relational database field. 

In some embodiments, ontology information from the structural ontology specification 
is used to automatically generate at least one of: a user interface configuration file such as a 
user interface search configuration file or a user interface product display configuration file; a 
search interface configuration file such as a search interface initial database request 

10 configuration, file or a search interface product detail request interface configuration file; a 
product catalog configuration file such as a catalog mapping sheet configuration file or a 
catalog enumeration load sheet configuration file; a file containing a user interface quality 
assurance checklist; a file containing a search interface quality assurance checklist; a file 
containing a framework of a script for extracting product data from a text file; a file containing 

15 a framework of a script for loading product data into a product relational database; a file 

containing a product data quality assurance script; a configuration file for a graphical product 
data entry tool which accepts product data entered manually by a user and places the product 
data in a product relational database; and a file containing documentation which describes 
product data that is requested from a supplier regarding products to be offered in the electronic 

20 commerce marketplace. 

Computer-readable storage media embodiments are properly configured when they 
contain program code to perform a method of the invention. A computer system embodiment 
comprises a processor and a memory accessible to the processor. The memory stores (and is 
thus configured by) an express structural ontology specification for a particular electronic 

25 commerce marketplace. The system is further configured by software for the processor which, 
when executed, uses ontology information read from the structural ontology specification to 
generate configuration materials for the electronic commerce marketplace. 

The express structural ontology specification preferably serves as the authoritative 
source of ontological information for the electronic commerce marketplace. For instance, in a 

30 web site development environment, a discrepancy in category names used in different 

configuration files can be resolved by referring to and relying on the category name(s) used in 
the express structural ontology specification. Other features and advantages of the present 
invention will become more fully apparent through the following description. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

To illustrate the manner in which the advantages and features of the invention are 
obtained, a more particular description of the invention will be given with reference to the 
attached drawings. These drawings only illustrate selected aspects of the invention and thus do 
5 not limit the invention's scope. In the drawings: 

Figure 1 is a diagram illustrating a prior art approach to commercial web site creation 
and maintenance, in which product data from a single vendor's catalog is entered manually for 
use by interactive tools that produce the web site, and the structural ontology of the web site is 
implicit in the internal code and data of such tools. 
10 Figure 2 is a diagram illustrating another prior art approach to commercial web site 

creation and maintenance, in which site ontology is somewhat more subject to control, in that 
several vendors agree on a structural ontology for the site, and yet use is not made of an 
express structural ontology specification to automatically generate configuration files for the 
site. 

15 Figure 3 is a diagram illustrating prior art systems and methods that focus on 

transactional ontology rather than structural ontology. 

Figure 4 is a diagram illustrating tools and techniques according to the present 
invention for using an express structural ontology specification to generate configuration files 
for at least one marketplace, and then configuring the at least one marketplace accordingly. 
20 Figure 5 is a flow chart illustrating methods of the present invention for using an 

express structural ontology specification to generate marketplace configuration files. 

Figure 6 is a flow chart further illustrating embodiments of an ontology information 
extraction step shown in Figure 5. 

Figure 7 is a flow chart further illustrating embodiments of a configuration file 
25 generation step shown in Figure 5. 

Figure 8 is a flow diagram illustrating use of an express structural ontology 
specification according to the invention to facilitate configuration of an operational 
marketplace. 

Figure 9 is a flow diagram illustrating data tools, product data load scripts, and 
30 databases in a marketplace architecture configured according to the invention. 

Figure 10 is a flow diagram illustrating procurement applications, enterprise resource 
planning systems, and a product catalog system in a marketplace architecture configured 
according to the invention. 
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DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

The present invention provides tools and techniques for facilitating electronic 
commerce marketplaces by automatically generating finished and/or template configuration 
files for a given marketplace from an express structural ontology specification. Although this 
5 Detailed Description is organized for convenience and clarity into several sections, it should be 
read as a whole, with attention to earlier or later portions as needed to aid understanding. The 
same holds true of the entire current application. 



Incorporation by Reference 

10 This application claims priority to and incorporates by reference the following United 

States provisional applications: serial no. 60/274,595 filed March 10, 2001, serial no. 
60/278,558 filed March 23, 2001, and serial no. 60/280,196 filed March 30, 2001. For clarity 
and reader convenience, some of the material from incorporated provisional applications is 
expressly, repeated herein, while other material (such as some multi-page script source code) is 

15 not so repeated but is included instead through incorporation by reference. 

Overview 

As an introductory example, Figure 4 illustrates embodiments of the present invention 
in which several marketplaces A, B, and C each have a respective structural ontology 400, 402, 

20 404. As indicated, the invention focuses on structural ontology rather than transactional 
ontology. In particular, an express structural ontology specification 408, 410, 412 exists for 
each respective structural ontology 400, 402, 404. A given express structural ontology 
specification 406 may be the result of negotiations between marketplace vendors, as suggested 
in Figure 2, and need not be automatically generated. However, the specification 406 must be 

25 express, not merely implicit in computer programs' internal code and data as is the case with 
approaches like that shown in Figure 1 . 

As confirmed by Figure 4, the invention provides tools 414 and techniques for 
facilitating multiple electronic commerce marketplaces such as marketplaces A, B, and C by 
automatically generating configuration materials 416, 418, 420 for the respective marketplaces. 

30 The invention may alternately or additionally be used to generate 414, from the different 
versions over time of a single marketplace express structural ontology specification 406, 
corresponding versions over time of configuration materials for that marketplace. Generated 
configuration materials may include complete or partial search page load files, product detail 
display load files, catalog files, data tool configuration files, QA checklists, and others 
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discussed herein. The materials generated 414 from the express structural ontology 
specification 406 according to the invention are then combined with other items to create the 
operational marketplace web site, documents, configured tools, and other elements of a 
configured marketplace 422, 424, 426. For instance, load files produced with the invention 
may be combined with product data and conventional database software to populate a product 
database. Document templates produced with the invention may be tailored to specific 
suppliers by adding names and addresses. Data tool configuration files produced with the 
invention may be used to configure data tools such as a catalog transfer manager. 

As confirmed in Figures 5-7, embodiments of the invention can facilitate a plurality of 
electronic commerce marketplaces and/or marketplace versions; the illustrated embodiments 
include or perform an obtaining step 500, a parsing step 502, an extracting step 504, and a 
generating step 506. The invention provides tools for performing these steps, such as 
configured computer systems and configured computer media 

During the obtaining step 500, a system for performing the method is provided with an 
express structural ontology specification 406 for a particular electronic commerce marketplace. 
A marketplace may be one of several coexisting marketplaces, or it may be a particular version 
of an evolving marketplace, or both. The structural ontology specification 406 expressly 
specifies ontology information such as product categories, product generic attributes, and 
product category attributes. One example of rules for implementing an express structural 
ontology specification 406 in a spreadsheet format 804 is 9 shown below, beginning with the 
column headings: 

I Database | Att_ | Node_ | Print | Family | Search | Field 
I 

I Category | Def_ | Id | File | Attribute | Method | Name | 
I Name | Id ~ | | | | | | 

I Data | PIMS | Req'd? | Website I Allowed 1 

I Type | Mapping | Y or N | Category! values | 

II || Name | (for ENUMs) | 

In particular: 
Database Category Name 
Prod_Att_def_id 
Default_node_id 



- Shows up on web-site exactly as entered. Be sure all cells below 
category name are clear. 

- Assigned by PIMS Administrator when data is ready to be 
pushed (make sure all cells are clear) 

- Assigned by PIMS Administrator when data is ready to be 
pushed (make sure all cells are clear) 
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Only on row with Category filled in. Names load files. AH 
capitals, no blanks, prefer 8 characters or less. 
Shows up on web-site exactly as entered. No constraints except 
50 characters max. 

Four options: textbox, drop-down, radio, or none. 
Truncated version of Attribute name, becomes field name in 
PIMS' Oracle database. No capitals, no blanks (use underscore), 
no slashes, no special characters such as # (use text only). 
Three basic entries: boolean-char(l) for radio buttons (any 
Y/N attribute); enum-varchar2(x) where x = 50, 250, 500, or 
1000 characters; number(x.y)-varchar2(z) where x is total number 
of digits y is digits to right of decimal point z = 50, 250, 500, or 
1000 characters 

Always use PROD GAyyXz where yy « field size (1 ,50, 250, 
500, or 1000 characters) z = a sequence number that 
increments by one for each value of the same size 
To avoid conflicts with standard Chemdex PRODJ3A numbers, always start the PROD GA 
numbers at the following starting values (for each Database Category Name): 
PRODJ3A1X7 PRODGA50X1 PROD_GA250X3 PRODJ3A500X5 
PRODJ3A1000X1 

Required (Y or N) - Unless absolutely needed, use N (otherwise, may not be able to 

load products if an attribute is not given by the supplier). 
Website Category Name - Always leave blank. 

Allowed Values (ENUMS)- Always leave blank for textbox searches. Always leave blank for 
boolean radio boxes. No leading or trailing spaces, no &. Capitalize the first letter of each 
word (but maintain proper nomenclature, e.g., NEMA, pH, mA) As last step, put all ENUMs 
on one line and separate by semicolon followed by a space (e.g., Enuml; Enum2; Enum3; 
Enum4). 

Other rules may also be used; indeed, a somewhat different set of rules for completing a 
specification 406 is given later in this application. Regardless, the specification 406 should be 
organized in a predefined format so that it can be parsed 502 by a suitably programmed 
computer; familiar parsing tools and techniques such as those used in parsing computer source 
code may be readily adapted for use in parsing specifications 406 according to the present 
invention. Parsing 502 proceeds according to the syntax (format) of the specification 406. 
When a particular piece of ontology information such as a product attribute is located during a 
pass through the specification 406, the value given for that piece of information is extracted 
504 by being copied to another memory location by the parsing and extraction software. The 
software which automatically parses 502 the specification 406 and extracts 504 ontology 
information from it can also parse other structural ontology specifications written in the 
predefined format and similarly extract ontology information values from them. The structural 
ontology specification 406 is an express specification rather than being merely implicit in 
computer program code. In addition to being in a format that can be parsed 502 by software, 



PrintJFile 

Family Attribute 

Search Method 
Field Name 

Data Type 
PIMS Mapping 
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this means that the specification 406 is human-readable. Indeed, it is preferably 
comprehensible to people who are not skilled as computer programmers. 

In some embodiments the parsing step or tool 502 performs quality assurance tests on 
the submitted specification 406, either as a precursor to the extraction 504 pass or in a manner 
5 interleaved with extraction 504 operations. Some quality assurance tests may also be 
conducted "manually", that is, by visual inspection, since the specification 406 is human- 
readable. Some of the mistakes in an express ontology specification 406 which can be detected 
manually and/or by a QA script or other QA software include: repeated or missing digit in a 
default node ID (e.g., 11181 instead of correct value 1181); use of dash instead of correct 
10 underscore, or vice versa (e.g. attribute identified as "meter-size" instead of correct 

"meter_size"); wrong searchability specified (e.g., "drop-down" instead of "text box" for a 
given attribute); wrong data size specified (e.g., "varchar2(250)" instead of "varchar2(50)"); 
blank lines at end of ontology spreadsheet file contained invisible cell reference which should 
not be there because the cells should instead be clear, category(ies) missing. PIMS mapping, 
15 search, and data types can also be checked. 

In one embodiment, an ontology specification 406 QA script checks for the following 
conditions before the invention attempts to generate configuration files from the express 
specification 406, and provides error or warning messages accordingly: 

File Format 
20 ===== 

Error if blank lines exist within the file 

Error if the # of columns is not correct (more or less = bad) 

Error if there are more header lines than are expected 

25 Data types and sizes 



Error if node_id is not a number (of X digits) 

Error if prod_att_def_id is not a number (of X digits) 

Warn if Database Family Name entries are more than 50 characters long. 

30 

Uniqueness 



Error if node_id is not unique within the file 
Warn if prod_att_defJd is not unique within the file 
35 Error if entries in PIMS Mapping field are not unique within a family 
Error if entries in the Family Name field are not unique within a family 

Allowed values checks 

40 Error if entries in Required field are not the allowed values (T, F) 
Error if entries in Search Method field are not the allowed values 
Error if PrintFile field contains spaces, special characters other than 

10 
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lowercase letters. 

Error if PIMS Mapping field entries are not in the right format 
Error if entries in PIMS Mapping field use restricted values 
Error if entries in PIMS Mapping field have values beyond what is allowed 
5 (PRODGA 50X5000, PROD_GA5000X2) 

Once the ontology specification 406 is checked and corrected, it is assumed to be in its 
final state (for that version of the ontology), with the possible exception of changes to enum 
values. In subsequent versions of the ontology specification 406, fields may be added, for 

10 instance, to meet the requirements of a newer version of a catalog system 822. Other changes 
to an express structural ontology specification 406 to produce a new version may include, 
without limitation, removing extra spaces from enums, shortening enums to meet generic 
attribute name length requirements, spelling corrections in enums and family names, and the 
addition of attributes for reasons such as refining the classification of products. In one case, an 

15 att_defjd was added to one column in a spreadsheet embodiment 804 of the express structural 
ontology specification 406, and node_id was added in another column, to help create 506 
configuration files such as enum files and mapping sheets. 

The invention uses ontology information extracted 504 from the structural ontology 
specification to automatically generate 506 configuration files for the electronic commerce 

20 marketplace. Many such configuration files were well known prior to the invention. However, 
they were generated by hand, or at most in a limited automatic manner that did not use an 
express structural ontology specification as a basis for creating them. Such prior approaches to 
configuration file generation failed to provide some or all of the advantages of the present 
invention, such as the relative ease of preparing revised configuration files to reflect an 

25 ontological change, and increased consistency among the configuration materials used by a 
given marketplace. 

Figure 6 illustrates in greater detail both the type of ontology information that may be 
defined in the format of a given specification 406, and the corresponding extraction 504 steps 
that can be used to extract that information from the specification 406. Corresponding parsing 

30 502 details are not shown but will be understood by those of skill in the art For instance, the 
specification 406 may specify data types (e.g., string, integer) for attributes, in which case a 
corresponding parsing 502 step locates the attribute name and the string or enumeration value 
that indicates the attribute's data type, and a corresponding extracting step 600 extracts the 
attribute name and the data type indicator from the specification 406. Likewise, parsing and 

35 extracting steps may be used on specifications 406 that specify attribute data size 602, the 
allowed values of an attribute 604, attribute search type 606, the mandatory 608 or optional 
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610 nature of a given attribute, and/or a mapping 612 between an attribute and a field in the 
relational database of product data. A given embodiment of the invention may include zero or 
more of these elements. 

More generally, the method steps and system elements shown in the Figures may be 
repeated, omitted, renamed, and/or grouped differently in a particular embodiment, except as 
required by proper interpretation of the claims granted. Method steps may be performed 
concurrently and/or in a different order than shown, except to the extent that a result of one 
step is needed by another step, or to the extent that a particular order is required under a proper 
interpretation of the claims granted. 

Figure 7 illustrates in greater detail both the type of configuration materials that may be 
automatically generated from a given specification 406, and the corresponding generation 506 
steps that use extracted 504 ontology information from the specification 406 to create the 
configuration materials. Corresponding uses of the configuration materials in the final 
marketplace are not shown in this Figure but will be understood by those of skill in the art. As 
with the other Figures, elements may be repeated, omitted, renamed, reordered, and/or grouped 
differently in different embodiments of the invention. In some embodiments, the method uses 
ontology information extracted 504 from the structural ontology specification 406 to 
automatically generate 506 configuration files by one or more of the following automatic 
generation steps: generating 700 a user interface configuration file such as generating 702 a 
user interface product display configuration file and/or generating 704 a user interface search 
configuration file; generating 706 a search interface configuration file such as generating 708 a 
search interface initial database request configuration file and/or generating 710 a search 
interface product detail request configuration file; generating 712 a catalog configuration file 
such as generating 714 a catalog enumeration load sheet configuration file and/or generating 
716 a catalog mapping sheet configuration file; generating 718 a quality assurance checklist 
such as generating 720 a search interface quality assurance checklist and/or generating 722 a 
user interface quality assurance checklist; generating 724 a product data quality assurance 
script; generating 726 a framework of a script for extracting product data from a text file and 
loading the product data into a product relational database; generating 728 a configuration file 
for a graphical product data entry tool which accepts product data entered manually by a user 
and places the product data in a product relational database; and/or generating 730 a file 
containing documentation which describes product data that is requested from a supplier 
regarding products to be offered in the electronic commerce marketplace. Computer systems 
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and/or computer-readable media specifically configured to operate/cause operations according 
to a method of the invention also embody the invention. 

Figures 8 through 10 further illustrate the architecture and context of the invention. 
Domain-specific knowledge 800 pertaining to a particular marketplace is captured by and/or 
5 from domain experts using an ontology capture tool 802, 41 4 to produce an express structural 
ontology specification 804, 406 for the particular marketplace at a particular point in time. The 
structural ontology specification 804 is express in that it is not embedded in computer code but 
is instead easily read, understood, and modified by people who are not necessarily trained as 
computer programmers. The ontology specification 804, 406 is structural as opposed to being 
10 transactional, in that it specifies relatively static aspects 800 of a marketplace such as the 
products, their attributes, and their relationships to one another, rather than specifying more 
dynamic aspects of the marketplace such as purchase orders 310. In one embodiment, the 
ontology is captured into a spreadsheet file 804 using a spreadsheet program 802. 

Scripts, macros, and/or other code 806, 414 are used to generate 506 configuration 
15 materials 808 such as configuration files 700-716, 728, checklists 718-722, scripts 724, script 
frameworks (partial scripts) 726, and/or documentation 730 for the particular marketplace. 
These configuration materials 808 are generated 506 from the marketplace's express structural 
ontology specification 804, 406. The various generated 506 script output files 808 are used to 
tailor a marketplace technology system 810 having generic components, thereby producing a 
20 more fully configured marketplace system 814 having components that are tailored according 
to the particular structural ontology of the marketplace. Suitable components of the system 810 
may include data management tools 8 1 8; a catalog system 822; Quality Assurance (QA) tools 
824 such as user interface QA checklists 722, search interface QA checklists 720, and QA 
scripts 724; and a procurement system 820 having user and search engine interfaces. Such 
25 components are generic when they have not yet been configured to match the ontology 
specification 406. 

After being configured according to the specified ontology, the catalog system 822 has 
product attributes and categories according to the specified structural ontology but it does not 
necessarily yet have data for particular products. The configured procurement system 820 
30 likewise has formats for search pages 1006 and product detail display pages 1 008 but does not 
necessarily yet have access to a complete database 920 of product data. The configuration files 
808 are generated 506 automatically with the invention, and then installed (implemented) by 
familiar operations in the generic marketplace system 810 in order to produce the configured 
marketplace system 814. 

13 
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Automatically generated files 808 are also used by marketplace business units 812 to 
facilitate marketplace business operations. For instance, in some embodiments output files 808 
generated 726, 724 from the ontology specification 406 are used by a content engineering 
department for data extraction 828 and QA 826. A QA script 828 can be generated 506 from 
5 the ontology specification 406 to check the user interface against the ontology. Such checks 
may identify, e.g., categories or families in which attributes are missing, and/or attributes (e.g., 
drop-down lists) that are missing enums or list entries. The result of the check can be 
documented in a spreadsheet or other file produced by the QA script. Output files 808 
generated 730 from the ontology specification 406 may also be used by the supplier relations 

10 department in creating data acquisition collateral 830 such as documents which help suppliers 
understand more clearly what data about their products is needed for the catalog 822. 

These more fully configured marketplace operational processes 816 and the fully 
configured marketplace technology system 8 14 are populated with product data to produce an 
electronic commerce marketplace 832 which is configured with product data in the specified 

1 5 ontology. This need not be a production marketplace, but can be instead a staging (testbed) 

marketplace which uses "maintenance" search collections 908 and product data 906, and which 
is then released for use - after appropriate testing and corrections/revisions to include 
operational search collections 922 and product data 920 - as an operational marketplace 834. 
In some embodiments, the search collections 908, 922 and databases 906, 920 are part of the 

20 PIMS (Product Information Management System) system 918, which is a catalog system that 
was apparently used by Ventro and its clients before the earliest of the incorporated provisional 
application filing dates. 

Note that parts of this overall process for configuring a marketplace with files 808 
generated (at least in part) from the ontology specification 406 may be repeated in response to 

25 changes in that ontology specification 406. For instance, after the specification 406 is changed, 
the scripts 806 can be run on it once again, to generate new configuration files 808 which are 
then installed in the system 810. Facilitating such reconfigurations is an advantage of the 
invention. 

In addition to points made above, the following may be noted in connection with Figure 
30 9. A web catalog manager 900, a contract price manager 902, and a catalog transfer manager 
904 are examples of data tools 818. These tools 900, 902, 904 may share a single user 
interface. The web catalog manager data tool 900 provides an HTML form for product data 
entry into a product database 906, e.g., an Oracle-brand relational database which is organized 
according to a database schema. The web catalog manager 900 normally depends on the 
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ontology, and hence it should be configured (or reconfigured) to reflect the specification 406. 
The contract price manager data tool 902 helps track buyer-specific pricing information, 
promotional offers, volume discounts and the like; it generally does not depend on the 
ontology specification 406. The catalog transfer manager data tool 904 assists in transferring 
5 product data from fiat files, through FTP and the like into the product database 906; it may 
depend on the ontology, or it may deal only with database fields that are specified in files 910 
provided by a supplier to be uploaded into the database 906. 

Data may also be loaded into the database 906 by load scripts 828 from a DBA 
department. The data loading scripts 828 may be provided by a product database administrator 

10 or product database administration department, in cooperation with a content engineering 
department 912. Load sheets may be generated 726 to reflect the ontology specification 406. 
That is, the express structural ontology specification 406 may be used as input to automatically 
produce 506 Perl modules (or frameworks thereof) for product data parsing and to create 726 
load files for loading product database content into the catalog system 822. The content 

15 engineering department 912 accepts raw product and price data 914 from suppliers, and 

processes it to produce formatted files 916 for uploading product data into the database 906. 
Such processing may include "physical data normalization" which moves data from PDF, word 
processor, and other software application-specific file formats into a shared file format; such 
physical normalization does not generally depend on the ontology specification 406. Content 

20 engineering may also perform 'logical data normalization" which conforms the data with the 
marketplace ontology, both by manual means and by automation tools 414. Content 
engineering may also perform "data quality assurance", both manual and automated, such as 
using the QA tools 826. 

The express structural ontology specification 804, 406 is preferably used according to 

25 the invention to automatically generate 506 ontology-specific files which configure the 
following to match the marketplace's specified ontology: web catalog manager 900, load 
scripts 828, logical data normalization scripts/script frameworks for content engineering 912, 
documentation 830 which tells suppliers what raw product data is needed from them, the 
product maintenance database 906, and the production (a.k.a. "operational") database(s) 922. 

30 However, not every one of these need be configured in every instance or every embodiment 

In addition to points made above, the following may be noted in connection with Figure 
10. In operation, the procurement application 820 performs various functions in various 
versions (e.g., in the commercially used Tradex-brand application), such as providing help 
pages, providing a user interface for other applications in addition to the procurement 
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application, performing order status and fulfillment tracking, performing other order 
management functions, supporting a shopping cart, supporting designation of company favorite 
products and/or individual user favorites, supporting workflow and approvals management, 
supporting various user preferences or profiles, and login/authentication operations. These 
functions are generally not tailored according to the marketplace ontology specification 406. 

However, the procurement application 820 also presents a user with search functions 
through a search user interface 1006. Searches and their results (as displayed to the user) may 
be tailored according to the ontology specification 406. For instance, a search may specify a 
product category. Search criteria entered in the search user interface 1006 by the user are used 
by the procurement software 820 to generate a corresponding search request 1010 to the 
database 920 in SQL or another database language. The search request results are then 
displayed to the user through a product display 1008 in the user interface. If more information 
about a given product category or individual product is desired, the user may narrow the search 
using a product detail portion of the user interface 1006, which is used to generate a 
corresponding product detail search request 1012, whose results are displayed to the user 
through a product detail portion 1 008 of the user interface. 

A buyer procurement application 1022 may be used, such as one of the applications 
provided by Ariba, CommerceOne, 12, ERP Systems, or other vendors. Such applications 1022 
provide functions such as order generation (including search), order management, order status 
and fulfillment tracking, user management, user authentication, workflow and approval 
tracking, accounts receivable, accounts payable, general ledger, and so forth. These buyer 
procurement applications 1022 are generally not configured according to the invention to 
reflect the ontology of the marketplace. 

A marketplace ERP (Enterprise Resource Planning) system 1014 with one or more 
Application Program Interfaces 1016 (e.g., the Chemdex API "CAPP, a Dot Connect-brand 
API, and a MarketLink-brand API) communicates as indicated in Figure 10 with the 
procurement applications 820, 1022. The ERP system 1014 provides functions such as 
accounts receivable, accounts payable, general ledger, order information management, vendor 
information master management, and buyer information master management. The ERP system 
1014 may include ERP software 308. The ERP system 1014 may communicate as indicated 
with a marketplace data warehouse 1018 used for business intelligence reporting, and with 
various supplier transaction systems 1 020 for order entry, fulfillment, product warehouse 
management, and billing/financing. The ERP system 1014, marketplace data warehouse 1018, 
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and supplier transaction systems 1020 are generally not configured according to the invention 
to reflect the ontology of the marketplace. 

As indicated in Figure 10, the procurement applications 820, 1022 communicate with 
the marketplace product catalog system 822; suitable catalog systems include at least some 
5 PIMS systems 918. The catalog system 822 provides features such as functionality for a 
product catalog/data repository, pricing lists, pricing based on volumes and/or times, buyer- 
specific pricing, contract information, vendor information, vendor rankings, and/or search 
capabilities. The catalog system 822 includes APIs 1002, such as PIMS or MarketLink APIs. It 
also includes a database management system 920, such as one using commercially available 

10 Oracle or Verity software and conventional disks, RAID, or other storage hardware. The 
product database 920 is organized according to a database schema which is not necessarily 
marketplace-specific. The product catalog, by contrast, is organized according to attributes and 
other metadata 1004 based on the marketplace's specified ontology 406. For instance, catalog 
metadata 1 004 may specify product categories, attributes, allowed data values, data types, data 

15 sizes, and so on. Conceptually, the metadata 1004 appears in the front half of the catalog; the 
back half includes the database 920 and its attendant database query language and database 
fields. 

The express structural ontology specification 406 is preferably used according to the 
invention to automatically generate 506 ontology-specific files which configure the following 
20 to match the marketplace's specified ontology: user interfaces for searching 1006 and product 
display 1008, search interfaces for the initial request 1010 and the product detail request 1012, 
and the product catalog front half 1004 (as opposed to the catalog's internal back half, which 
interfaces with the product database 920). However; not every one of these need be configured 
in every instance or every embodiment 

25 

Additional Examples, Definitions, and Their Use 

In describing embodiments of invention, the meaning of several important terms is 
clarified by express definitions and/or by examples, so the claims must be read with careful 
attention to these clarifications. Specific examples are given herein to illustrate aspects of the 
30 invention, but those of skill in the relevant art(s) will understand that other examples may also 
fall within the meaning of the terms used, and hence within the scope of one or more claims. 
Important terms may be defined, either explicitly or implicitly, here in the Detailed Description 
and/or elsewhere in the application file(s). The invention may be embodied in various ways, 
and it may also be described in various ways. Accordingly, the examples discussed throughout 
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this document are not necessarily consistent with one another in every particular; rather than 
omitting details to achieve complete consistency, details are included if they may assist in a 
better understanding of some embodiment of the invention. 

The following terms are preferably used in the indicated manner in at least some 
embodiments of the invention. Hie information below includes both examples and definitions; 
those of skill will understand whether particular details can or must be omitted from, or varied 
within, a given embodiment Note that the terms "marketplace" and 'Vertical" may be used 
interchangeably. 

ATTRIBUTES: One element of an ONTOLOGY. Attributes are aspects of a product 
which are distinguishing, important, descriptive, and/or informative. There are generic 
attributes, which every product in a marketplace will have (such as name or catalog number), 
and there are family-specific (or category-specific attributes) which only products in the same 
family will share (such as a "Composer Name" or "ISBN Number"). Attributes are assigned to 
a product according to the product's CATEGORY, and are mapped onto the product in the 
database via the ATT_DEFJD. Attributes themselves have attributes or characteristics which 
are important to capture in an ontology, such as if the attribute is required or not, if it's 
searchable, how it's searchable, its data type and size, its allowed values, etc. 

AWK: A pattern scanning and processing language utility found on many UNIX 
systems. AWK may be used with stream editor SED to create or modify scripts according to 
the invention in Perl or other scripting languages. SED and AWK are widely used and 
understood, and are not, in and of themselves, claimed as part of the invention although they 
may be used to help implement parts of the invention. Likewise, although Perl is used in many 
of the examples given here, other scripting languages, and other programming languages, may 
be used in other embodiments of the invention. Scripting languages and their interpreters are 
widely used for various purposes, but their use according to the present invention is believed to 
be new. They are not, in and of themselves, claimed as the present invention. 

B20: This stands for "build 20" and refers to a specific version of the Ventro front-end 
UI and procurement system. The use of "B20-compafible" indicates that that entity is usable 
with (or to be configured with) that version B20 of the front-end user interface and 
procurement system. 

CATEGORIES: One element of an ONTOLOGY. The product space sold by a 
marketplace is divided up into CATEGORIES, and every product sold by the marketplace is 
assigned to map into one of these categories. Categories are displayed as the result of certain 
kinds of searches on the procurement system's user interface. Also, the category assignment of 
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a product will control which attributes are assigned to that product Products are mapped into 
categories in the database via the NODEJD. 

CES: Content Engineering Services. Usually refers to the Ventro department which 
works with Marketplace customers doing catalog and content consulting/training. Can 
5 occasionally refer to the marketplace's department which produces catalog and content. 

CONFIG FILES, CONFIGURATION FILES: In a narrow sense, each of these phrases 
refers to files needed to configure PIMS (or other catalog systems) and data tools for a given 
marketplace, to configure the procurement systems search interface and product display 
screens, to display search results from a vertical's search engine, and to create DBA load files. 
10 Examples include PIMS MAPPING SHEETS, PIMS ENUM LOAD SHEETS, UI CONFIG 
FILES, UI LOAD SHEETS FOR SEARCH PAGES, UI LOAD SHEETS FOR PRODUCT 
DETAIL DISPLAY, SUPPLIER TOOLS UI CONFIG FILES. In a broader sense, 
configuration files are files that are automatically generated - in part or in their entirety - from 
the ONTOLOGY SPEC SHEET according to the invention. In this broader sense, config files 
15 (also called "configuration materials") include quality assurance checklists and scripts, and 
documentation for suppliers, generated according to the invention and noted at steps 718, 720, 
722, 724, and 730 in Figure 7. 

Step 730 may be implemented in a manner similar to the implementation of step 718. 
See also the checklistxls and report. txt files noted elsewhere in the application(s), as they are 
20 likewise instructional text documents, for end-user use, that are generated 506 from an 
ONTOLOGY SPEC SHEET 406. 

CONFIG FILE GENERATION SCRIPTS: Perl scripts which automatically generate 
CONFIG FILES and other ONTOLOGY-specific output from an instance of the ONTOLOGY 
SPEC SHEET. Other scripting languages could also be used, as well as programs written in 
25 languages such as C, C++, Java, etc. These scripts are also known as vertical buildout scripts, 
buildout scripts, and vertical generation scripts. 

CVS: The "Concurrent Versions System". CVS is the version control system used at 
Ventro to house and manage source code and other configuration files for the Ventro platform 
and a marketplace's specific set of source code. CVS is generally similar to the RCS and SCCS 
30 version control systems. Version control systems are widely used and understood, and are not, 
in and of themselves, claimed as part of the invention although they may be used to facilitate 
embodiments of the invention. 

DBA: The database administration group, or sometimes an individual database 
administrator. 
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DBA LOAD SCRIPTS: A set of SQL and ProC modules used to load ASCII data files 
into PIMS. These modules are specific for each CATEGORY of product, so a given 
marketplace will have many modules which need to be produced, based on the ONTOLOGY. 

ENUM: An enumeration data type indicating an ATTRIBUTE which can only be 
populated with certain predetermined, allowed values (e.g., the attribute eye_color is an enum 
with values blue, green, grey, brown, other). Alternately, one member of a set of allowed 
values assigned to an ATTRIBUTE (e.g., the value grey is one of the ENUMS of the eye_color 
attribute). ENUMS are stored in the enum table in PIMS where a counting number (1,2,3...) is 
bound to each specific attribute value. 

FAMILIES: Used interchangeably with CATEGORIES. 

FE group: This refers to the "front-end group", which is a group of developers who 
oversee creation and customization of the user interface and procurement system. 

GA: A generic attribute in Ventre's Product Information Management System (PIMS - 
the Ventro catalog system) which is configured by a marketplace's ontology to hold a specific 
product attribute. The attribute assigned to a given GA will vary by product family. 

NODEJD: A database value present in the PIMS product table and in the 
prod_tree_def table, which is used to map a product to a CATEGORY. 

ONTOLOGY: The information about how a marketplace will organize and portray 
products on its site and in its search engine, and how data in the marketplace's PIMS database 
will be stored and configured. Information in an ONTOLOGY may include category 
assignments, product attributes, and may also include information about the data type, data 
size, allowed values, searchability, and mandatory or optional nature of each product attribute. 
An ONTOLOGY may also include NODEJDs, PROD_ ATT_DEF_ID ' s and database field 
mappings to each CATEGORY'S ATTRIBUTES. 

ONTOLOGY SPEC SHEET: This is a specification sheet, that is an express description 
of the structural ontology in a standardized format (so it can be parsed and processed by the 
CONFIG FILE GENERATION SCRIPTS), which specifies the ONTOLOGY that is to be 
configured in a vertical's PIMS instance and presented through a vertical's search engine. The 
spec sheet has been implemented as an Excel spreadsheet, but could be implemented as a flat 
text file, as a sequence of database records, as an XML file, via a web-based user interface 
which generates one of those file-types, or in other ways. 

PIMS: Product Information Management System. Ventre's Oracle-database-system- 
based catalog system, search services, and API's. Used as the product data repository and 
search systems for Ventro and its marketplaces. One of PIMS' major components is the 
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product database; another is the product catalog built on top of the database. Each marketplace 
has its own installation of PIMS or another catalog system, customized for that marketplace 
based on the marketplace's ONTOLOGY. Hie invention is not limited to uses with PIMS. 

PIMS ENUM LOAD SHEETS: Refers to the generated 712, 728 file ("enumFile") 
5 used by the DBA group to load a marketplace's ENUM values into their PIMS instance. 

PIMS MAPPING SHEETS: Refers to the files generated by the CONFIG FILE 
GENERATION SCRIPTS in the "fMy_Attribute" directory. They are used by the DBA 
group to generate DBA LOAD SCRIPTS and for other PIMS configuration tasks. 

PRINTFILE: A Perl module used by a marketplace's CES team as part of scripted data 
10 processing. The PRINTFILE modules write the output of a data processing script to a file in 
the fonnat necessary for it to be loaded into PIMS using the DBA load scripts. These modules 
are specific for each CATEGORY of product, so agiven marketplace will have many modules - 
which need to be produced, based on the ONTOLOGY. 

PROD_ATT_DEF_ED: A database value present in the PIMS product table and in the 
15 prod_att_def table, which is used to map a product to a set of ATTRIBUTES. In one 

embodiment, the order of the entries in the prodattdef and the prod_ga files are different; 
each family will have different sets of PRODJjA's. Perl scripts use the ontology specification 
file 406 as a template to generate an auto.sh file, which is edited to dynamically generate 
loading scripts. 

20 PRODUCT TREE: Refers to the prodJree_def table in PIMS. This table contains 

CATEGORY names and NODEJD's. 

PROPERTIES FILE: A file used by the front-end marketplace development team to 

configure the procurement system front-end search pages or product detail display pages. 

There are three types of this file: ontology .properties, enum.properties and radio.properties. An 
25 example of an ontology.properties is given later in this application. One embodiment of the 

invention generates 700-710 an Enum.propertiesl file that includes text such as the following 

excerpt (ellipsis indicates similar omitted material): 

otherOther 

C2.A0.enumType=type 
30 C2.A0.segment=1023 

C2.A1 .enumType=materiaI 

C2.A1 .segments 023 

C2.A2.enumType=nuts 

C2.A2.segment=1023 
35 C2.A3 .enumType=diameter 

C2. A3. segmental 023 

C2.A4.enumType=length 



WO 02/073493 



PCT/US01/25468 



C2.A4.segment=l 023 



Another example from an enum. properties file is given in incorporated provisional application 
60/278,558 at pages 62-63. 
5 One embodiment of the invention generates 700-710 from the express specification 406 

a Radio.properties file that contains text such as the following; ellipsis again indicates similar 
omitted material: 

# The options for the attributes that are radio buttons 

# C# = the category ID 
10 # A# = the attribute ID 

# 0# = the option ID 

# TTL = the total number of radio options for each attribute 

# Augers-Drilling 

-15 #-gearbox — ~ 

C34.A2.O0=yes 

C34.A2.V0=T 

C34.A2.01=no 

C34.A2.V1=F 
20 C34.A2.02=dontcare 

C34.A2.V2=@null 

C34.A2.TTL=3 



# Terminal Blocks 
25 # other_awg 

C220A18.O0=yes 
C220A18.VO=T 
C220A18.Ol=no 
C220A18.V1=F 
30 C220A18.O2=dontcare 
C220A18.V2=@null 
C220A18.TTL=3 

# Wire and Cable 
35 # trayrated 

C223All.O0=yes 
C223A11.V0=T 
C223.A11.01=no 
C223.A11.V1=F 
40 C223A11.02=don'tcare 
C223All.V2=@null 
C223A11.TTL=3 

In a more recent version of the front end application, the display page is autogenerated 

45 from the contents of the database, so the ontology .properties, enum.properties and 

radio.properties configuration files are used differently. 
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Notation such as "700-71 0" indicates that one or more of the listed components 700 
through 710 is present in the embodiments) being discussed. It does not mean that all of the 
listed components (e.g., 700, 702, 704, 706, 708, and 710) are present in a given embodiment, 
although they may be. Nor does it mean that every embodiment of the invention must include 
one or more such components. 

QA: Quality Assurance. This is sometimes used generally, and sometimes used 
specifically with regard to the ONTOLOGY SPEC SHEET. With regard to the ontology spec 
sheet (aJca., "express structural ontology specification"), quality assurance may include 
manually checking the sheet for consistency with the vertical's desired design and using 
software to check the sheet for violation^) of unique constraints), formatting error(s), naming 
convention non-compliance, and/or other problems. Error or warning messages can be 
produced whenthe following are present jn a spec sheet:, re-used PROD_ATT_DEF_IDs _ 
(should generate a warning message when the config scripts are run, so that a content 
engineering person can check that case with the marketplace domain experts); use of dash "-" 
instead of underscore "J* in attribute name; character array declared larger than desired; use of 
invisible cell references in blank lines at end of spreadsheet; errors in file format, data types 
and sizes, uniqueness, or allowed values; CATEGORIES or FAMILIES with missing 
ATTRIBUTES, or attributes that have missing ENUMS or list entries. 

SED: A stream editor found on many UNIX systems; see also AWK. 

SUPPLIER TOOLS UI CONFIG FILES: Ventro provides marketplaces with web- 
based data management tools: Web Catalog Manager is a graphical way to enter data into 
PIMS, and Catalog Transfer Manager allows flat-file upload of data into PIMS. These tools 
must be configured according to a marketplace's ONTOLOGY. This can be done using the 
output of the CONFIG FILE GENERATION SCRIPTS to automatically configure these data 
tools as required. 

UI CONFIG FILES: See PROPERTIES FILE. This is a general way to refer to the set 
of all PROPERTIES FILEs. 

UI LOAD SHEETS FOR PRODUCT DETAIL DISPLAY: See PROPERTIES FILE. 
This is the file used by the procurement system user interface developers to configure the fields 
which appear on a products detail display page in the procurement system. These depend on a 
marketplace's ONTOLOGY. 

UI LOAD SHEETS FOR SEARCH PAGES: See PROPERTIES FILE. This is the file 
used by the procurement system user interface developers to configure the category-specific 
search pages in the procurement system. These depend on a marketplace's ONTOLOGY. 
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UI VALIDATION FILE: A text file containing the checklist of items which must be 
QA'ed in the procurement system user interface and in the marketplace's search functionality. 
This QA can be done manually or via scripts. This checklist is generated by the CONFIG FILE 
GENERATION SCRIPTS and is based on the marketplace's ONTOLOGY. 

5 

Comments on Computers 

Computers may be configured for use as tools 414, as components of a configured 
marketplace 814, and otherwise according to the invention. In general, it will be understood 
that scripts, applications, databases, files, interfaces, and the like refer to computers in that they 

10 run on computers, reside on computers, and provide control over computers. Suitable 

computers may be one or more of a workstation, a laptop computer, a disco nnectable mobile 
computer; a server, an embedded system, a mainframe, or a handheld computer, for instance. A - 
given computer may be a general purpose computer configured by software (e.g., scripts) 
according to the invention, or it may be a special purpose machine configured by ASICs, 

15 FPGAs, or the like. A processor may be a uniprocessor or a multiprocessor component of the 
computer. A suitable computer system often includes one or more user I/O devices such as a 
display screen, keyboard, mouse, microphone, speakers, touch screen, and so on. The computer 
system includes random access memory and may include other forms of memory such as ROM 
or PROM memory. The memory is in operable communication with the processor, and the I/O 

20 devices likewise communicate with the processor and/or the memory. 

The computer system is capable of using floppy drives, tape drives, optical drives or 
other means to read a storage medium. A suitable storage medium includes a magnetic, optical, 
or other computer-readable storage media having a specific physical substrate configuration. 
Suitable storage devices include floppy disks, hard disks, tape, CD-ROMs, DVDs, PROMs, 

25 RAM and other computer system storage devices. The substrate configuration represents data 
and instructions which cause the computer system to operate in a specific and predefined 
maimer as described herein. Thus, a given medium tangibly embodies a program, functions, 
and/or instructions that are executable by the computer system to perform one or more steps 
for facilitating electronic commerce substantially as described herein. 

30 The computers) in a system according to the invention may be connectable to one or 

more networks through network I/O hardware and/or software. By way of example, suitable 
computer networks include local networks, wide area networks, and/or the Internet. "Intenief ' 
as used herein includes variations such as a private Internet, a secure Internet, a value-added 
network, a virtual private network, or an intranet. A network may include one or more LANs, 
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wide-area networks, Internet servers and clients, intranet servers and clients, or a combination 
thereof. Such computer networks may form part of a telecommunications network and/or 
interface with a telecommunications network. The network's transmission media may include 
twisted pair, optical fiber cables, coaxial cable, telephone lines, satellites, radio waves, 
5 microwave relays, modulated AC power lines, and other data transmission "wires" known to 
those of skill in the art, as well as routers, bridges, caching appliances, and the like. Note that 
the term 'Svire" as used herein includes wired and/or wireless communications. Methods such 
as TDMA, CDMA, FDMA, and other encoding and/or multiplexing methods may be used, as 
well as GSM, PDC, Wireless Application Protocol, and other technologies and protocols. 
10 Signals according to the invention may be embodied in volatile and/or nonvolatile network 
transmission media. 

Although particular components are shown injhe Figures and/or discussed herein, - 
those of skill in the art will appreciate that the present invention also works with a variety of 
other networks and computers, as well as a variety of batch files, scripts, tools, and other 
1 5 software. To avoid repetition, it is assumed here that discussion of an inventive computer 
system will be applied by those of skill to promote understanding of the inventive methods, 
and vice versa. Likewise, the discussions of the inventive methods may be applied by those of 
skill to inventive computer storage media which are configured with software to operate 
according to the methods. 

20 

Example Ontology Specification Completion Rules 

In one embodiment, instructions for filling in an ontology specification 406 include the 

following; another such set of rules is given earlier in this application: 

Filling out the Ontology Specification Sheet 
25 The Ontology Specification Sheet (ontology spec sheet) is an Excel spreadsheet that 

contains information about product categories, category specific attributes, attribute search 
methods and attribute data types pertaining to a Ventro marketplace. 

Buildout scripts run off of the tab-delimited form of this file and generate database 
configuration files, product load scripts and the front-end properties files needed to create a 
30 Ventro marketplace. The ontology spec sheet is also used to configure Data Tools' Web 
Catalog Manager and Catalog Transfer Manager. 

The ontology spec sheet contains the following columns, in order from left to right: 

Database Category Name 
35 The Database Category Name is the product family or category name that is displayed 

on the front-end. 

The Database Category Name is loaded into the PRODJTREEJDEF table in PIMS as 
the NODEJJAME using the load file prodJree_def.out which is generated [712, 728] by the 
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buildout scripts. The prodJreejief.out load file contains the NODEJSFAME/NODEJDD 
pairings. 

The Database Category Name is included in the ontology.properties file also generated 
by the buildout scripts. This file is used by the front-end developers to configure the category 
5 search pages and the product detail pages. 

Att Def Id 

The Att_DefJd is an internal reference number, usually four to five digits in length, 
that is assigned to a set of family or category specific attributes. It must be numerical; no 
10 characters are allowed. 

The AttDefld is usually unique in a marketplace's ontology. The AttJDefld can be 
shared by more than one family; however, the set of attributes of each category must be the 
same. 

The Att_Def_Id is stored in three locations in the database. It is the primary key of the 
15 PROD_ATTJDEF table where it is called the PROD_ATT_DEF_ID. It is loaded into this table 
as part of the prod_att_def.out file which is generated [712, 728] by the buildout scripts. The 
Att JDefld is also loaded into the PRODUCT table with each new product record as the 
PROT_ATTJDER_ID. The last table the Att^ is loaded into is the ENUM table.- Here it 
is known as the PROJECTJSEGMENT. The load file for the ENUM table, enumjBle.out, is 
20 generated by the buildout scripts. 

Another file generated by the buildout scripts that utilizes the Att_DefId is the 
Enum.properties file. This file, along with the ontology.properties file, is used by front-end 
developers to configure the category search page for the attributes with a drop-down search 
type. 

25 

Node Id 

The Node Id is an internal reference number, usually four to five digits in length, that 
is assigned to a Database Category Name. This number MUST be unique in a marketplace's 
ontology. It must be numerical; no characters are allowed. 

30 The Node_Id is stored in two locations in the database. It is the primary key of the 

PRODJTREEJDEF table. The buildout scripts generate [712, 728] a load file, 
prod_att_def.out, which contains the Node_Jd/ Node Name pairing. This file is used to load 
the PROD_TREE_DEF table. 

The NODEJD is also loaded with each product record into the PRODUCT table as the 

35 DEFAULT_NODE_ID. The DEFAULTJSfODEJDD maps a product to its respective category 
name. 

Print File 

The PrintJFile is an abbreviated version of the database category name and is used to 
40 name a variety of load scripts and files. 

PrintJFile names are used by the buildout scripts to name the all tags text files. The 
product load script, qaTemplate.pl [724], to QA product load files, utilizes the all_tag files. 
The alljag files contains the data types, data sizes and allowed values for family specific 
attributes that are accessed by the QA script 
45 The PrintJFile name is also used by the buildout scripts in the load setup.out file. The 

load_setup.out file is used by the Database Engineers to programmatically generate [726] 
family specific product load scripts. The PrintJFile name along with the supplier short name is 
used to name family specific product load files. 

Because it is used to name files residing in the UNIX operating system, no spaces are 
50 allowed. Underscores are used instead. The PrintJFile name is always composed of upper-case 
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letters and cannot be longer than twenty-seven characters in length. Also, the Print J?ile name 
cannot contain any numerals. Please see formatting rules below for further restrictions. 

Family Attribute 

5 Family Attributes are the names of the family or category specific attributes that will be 

displayed on the front-end on the category search and product detail pages. 

The values entered here are included in the ontology .properties file generated by the 
buildout script. This file is used by the front-end developers to help configure the front-end 
category search and product detail pages. 
10 The names of searchable attributes will be shown on the category search page and the 

product detail page. Attributes with a search method of none will NOT appear on the category 
search page. Attributes with a search method of none will NOT appear on the product detail 
page unless otherwise specified. 

15 Search method 

The Search method specifies the method used for searching over a family or category 
specific attribute on the category search page. An attribute can have only one Search method. 

—The types of search method are text box (text string), drop-down (drop-down \ist)~radio 
(radio button) and none. A text box search allows the user to use any string of text they enter as 
20 their search query. A drop down search consists of a predetermined list of allowed values 
(drop-down list) that can be selected by the user for their search query. A search method of 
radio, as a default, allows the user to enter a yes or no argument as their query. An attribute 
with a search method of none is not searchable. 

Attributes with a search method of text-box, drop-down and radio will appear on the 
25 category search page and as a default, on the product details page. Attributes with a search 

method of none will NOT appear on the category search page. Attributes with a search method 
of none will appear on the product detail page only if there is a specific request that they do so. 

The Search method is tied to the Data Type (see below). Make sure they are 
compatible. Listed below are the appropriate pairings of Search Methods and Data Types: 

30 

Search method/Data Typ e 

text box: text-varchar2(n) or number(y i z)-yarchar2(n) where n equals the maximum 
number of characters or digits allowed in the field, y equals the total number of digits and z 
equals the number of digits to the right of the decimal point. The allowed values for n arc 50, 
35 250, 500 and 1000. 

drop-down: enum-varchar2(n) where n equals the maximum number of characters or 
digits allowed in the field. The allowed values for n are 50, 250, 500 and 1000. 

radio: boolean-charl 

none: varchar2(n) where n equals the maximum number of characters or digits allowed 
40 in the field. The allowed values for n are 50, 250, 500 and 1000. 

field name 

The database field name for the family attribute. It is stored in the PRODATTJDEF 
table as the primary key ATTJSfAME. The Field Name is an abbreviated version of the family 
45 attribute name. It is always in lowercase. No spaces are allowed; underscores are used instead. 
Please see formatting rules below for more details. The field name is incoporated by the 
ontology buildout scripts into the prod_att_def.out load file. 

Data Type 

50 The buildout scripts utilize the Data Type to help create the all_tags text files. The 

all Jags text files are utilized by the QA script qaTemplate.pl, to check data types, data sizes, 
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allowed values and whether or not required attributes have a value present in product load file 
prior to loading. 

Allowed values for this field are as follows: varchar2(n) for a search method of none, 
boolean-char 1 for a search method of radio, number (y.z)-varchar2(n) or text-varchar2(n) for a 
5 search method of text box. And ermm-varchar2 (n) for a search method of drop-down where x 
equals the maximum number of characters or digits allowed in the field. The allowed values 
for n are 50, 250, 500 and 1000. See Search method above. 

PIMS mapping 

10 The PIMS mapping specifies which column in the PRODUCT or SKU table a family 

specific attribute will be placed. These columns in the PRODUCT table are known as Generic 
Attribute or GA columns. 

A PIMS mapping is REQUIRED for every attribute listed on the ontology spec sheet 
The format for a PIMS mapping is PRODjQAnXy or SKJJJjAnXy. PROD stands for 
15 the PRODUCT table, SKU stands for the SKU table, n is the maximum field size (in bytes or 
the number of characters/numerals)and y is the sequential number of the generic attribute with 
the same field size in the same family. For example, PROD_GA500X6 is an attribute with a 

_ maximum field sizeof 500 bytes, and it is the sixth attribute in that family with a 500 byte field " " " 

size. 

20 There are a limited number of GA columns in the PRODUCT and SKU tables. Each 

field size has a limited number of columns. In the PRODUCT table there are 20 columns each 
with a field size of 1 , 50 and 250 bytes, 30 columns with a field size of 500 bytes and 1 0 
columns with a field size of 1000 bytes. In the SKU table there are 1 0 columns with a field size 
of 50 bytes. 

25 A number of the GA columns are currently set aside for regulatory and shipping related 

attributes. The GA columns unavailable are given in the formatting rules section listed below. 

When sizing columns for attributes, be certain the column is long enough to hold all of 
the data. A column with a data type of varchar2(n) will adjust the length of the column to fit 
the size of the data (providing its less than the maYimnm length, w). Do not needlessly waste 

30 large columns on attributes that will only have small data elements. 

PIMS mappings are loaded into the column COL NAME in the PROD ATTJDEF 
table in PIMS using the prod_att_def.out file. PIMS mappings are loaded into the column, 
COLUMN NAME, in the ENUM table in PIMS using the enum_file.out load file. PIMS 
mappings are also incorporated by the buildout scripts into the all_tags text files and the 

35 FamilyAttribute Excel files. 

Required? (Y or N) 

This column specifies whether a family specific attribute is required in the database. 
The allowed values are Y for required and N for not required 
40 This information is incorporated by the buildout scripts into the prod att def.out file. 

This file is loaded into the PROD_ATT_DEF table in the REQUIRED column. 

The information in this column is also incorporated into the all_tags text files. The 
alMags text files are utilized by the QA script, qaTemplate.pl, to check data types, data sizes, 
allowed values and whether or not required attributes have a value present in product load file 
45 prior to loading. 

A value of Y orN MUST be given for every attribute. 

Website Category Name 
Obsolete. 

50 
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Allowed Values 

Allowed Values are a set of given values for a particular family specific attribute. For 
an attribute with a search type of drop-dawn, only the values listed here can be loaded into the 
database. The Allowed Values constrain what values can be used to search over a particular 
attribute. This is done via a drop-down list on the category search page. 

The allowed values for an attribute should be in the order (left to right) that they should 
appear in the drop-down list (top to bottom). The first value in the drop-down list is the default 
of Any. Do not enter Any in the list This is inserted by the front-end developers later. Separate 
values by a semi-colon and then a space. 

The Allowed Values are loaded into the REPRESENTATION column in the ENUM 
table in PIMS. The load file, enum file.out, is generated by the buildout scripts. The other data 
elements in the enum file are: the PROJECT ID, PIMS, assigned by the buildout scripts, the 
PROJECTJSEGMENT is the attribute set's PROD_ATTJDEFJD, the 
COLUMN_SEGMENT is the PIMS mapping for the appropriate attribute, and the VALUE is 
assigned by the buildout scripts. The first Allowed Value has a value of 0, the second a value 
of 1, and so on. 

The Allowed Values in the ENUM table will be used to populate the drop-down lists on 
the category search pages on the fiont-end; - - - - - 

Ontology Spreadsheet Formatting Rules 
Universal rules 

1) Double quote marks (") are NOT allowed anywhere in the ontology spec sheet. 

2) Ampersands (&) are NOT allowed anywhere in the ontology spec sheet. 

3) Avoid special characters such as 

4) Avoid trailing spaces at the end of all of the fields. 

5) Empty rows are NOT allowed. 

6) A marketplace may have only one ontology spec sheet 

Database Category Name 

1) The value entered here will appear exactly as is on the category search and product 

return pages on the front-end. 

2) Can be no longer than 50 characters in length. 

3) Placed in the left-hand cell, at the top row, of a list of family specific attributes. 

4) All of the cells between Database Category Names must remain empty. 

5) Single quote marks are NOT allowed. 

Attj)efld 

1) Assigned by the marketplace. 

2) Usually four to five digits in length. 

3) Cannot be longer than 12 digits in length. 

4) Numeric field only. No letters or punctuation marks allowed.. 

5) In general, this number is unique in a marketplace's ontology. 

6) This number can only be shared by two categories that have exactly the same attribute 

set This includes having the same lists of allowed values in the same order. 

7) Placed on the same row as the Database Category Name. All of the cells between 
AttJDefJds must remain empty. 

Nodejd 

1) Assigned by the marketplace. 

2) Usually four to five digits in length. 

3) Cannot be longer than 12 digits in length. 
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4) Numeric field only. No letters or punctuation marks allowed. . 

5) This number is unique in a marketplace's ontology. A NodeJH cannot be shared by two 

or more families. 

6) Placed on the same row as the Database Category Name. All of the cells between 
5 Node lds must remain empty. 

PrintJFile 

1) Assigned by the marketplace. It's usually an abbreviated form of the Database Category 
Name. 

10 2) ALL IN UPPER CASE LETTERS. No lower case characters. 

3) Can be no longer than 27 characters in length. 

4) No spaces, commas or other punctuation marks allowed. 

5) No hyphens. 

6) Underscores can be used instead of spaces or hyphens. 
1 5 7) Numerals are not allowed. 

8) Placed on the same row as the Database Category Name. All of the cells between 

PrintFile names must remain empty. 

9) No trailing spaces. — ■ 

20 Family Attribute 

1) The value entered here will appear exactly as is on the category search and product 

return pages on the front-end. 

2) Can be no longer than 50 characters in length. 

3) There must be a value for every family attribute listed in the ontology spec sheet 

25 

Search method 

1) Only one of four options is allowed: text box, drop-down, radio, or none. 

2) There must be a Search method for every family attribute listed in the ontology spec 

sheet. 

30 

Field Name 

1) Usually is a truncated version of the Family Attribute name. 

2) Use only lowercase letters. No capital letters are allowed. 

3) No spaces are allowed. Use underscores instead. 

35 4) No punctuation marks are allowed, i.e. commas, single quote marks, semi-colons, colons 
etc. 

5) No trailing spaces. 

6) No longer than 50 characters in length. 



40 Data Type 

1) The data type is determined by the search method. 

2) The basic entries are: varchar2(n), boolean-char(l), enum-varchar2(n), text-varchar2(«) 

and number(x.y) varchar2(«), where n = 50, 250, 500, or 1000 characters, y equals the 
total number of digits and z equals the number of digits to the right of the decimal 
45 point. 

3) The pairings are: 

Search method Data Type 

a) none varchar2(/i) 

b) text box text-varchar2(n) or number(r. i y)-varchar2(n) 
50 c) drop-down enum-varhar2(n) 

d) radio boolean-char(l) 
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PEVTS Mapping 

1) Use PROD GAnXy or SKUGAnXy. Where PROD stands for the PRODUCT 
table; SKU stands for the SKU table. Where n is the maximum field size (in bytes or 
the number of characters/numerals). Where y is the sequential number of generic 
attributes with the same field size, in the same family. 

n = field size (1,50, 250, 500, or 1000 characters). 

>> = a sequence number that increments by one for each value of the same size. 

2) Case is important! The PROD_GA, SKU_GA and the X are UPPER CASE 
LETTERS. 

3) In general, the n in PIMS mapping and the n in data type are equal. The n in data 
type can be less than the n in PIMS mapping, but the n in PIMS mapping can 
NEVER be less than the n in datatype. 

4) To avoid conflicts with preassigned GA columns (mentioned above), do not use the 
following PROD_GA numbers: PROD_GAlXl to PROD_GAlX6; 
PRODGA1X20; PRODGA250X1; PROD_GA250X2; and PROD_GA500X1 to 
500X4. 

Required (Y or N) 

1) The only allowed values are Y for required and N for not required. 

2) This must be filled in for every family attribute. 

3) Unless absolutely needed, use N (otherwise, you may not be able to load products if an 

attribute is not given by the supplier). 

Website Category Name 
Always leave blank. 

Allowed Values (ENUMS) 

1) Always leave blank for attributes with a search method of text box. 

2) Always leave blank for attributes with a search method of radio. 

3) Always leave blank for attributes with a search method of none. 

4) No leading or trailing spaces. 

5) No ampersands (&). 

6) Values should be mixed case with the first letter of each word capitalized (but maintain 

proper nomenclature, e.g., NEMA, pH, mA). 

7) Values are separated by a semi-colon and a space (e.g., Enuml ; Enum2; Enum3; 

Enum4). 

8) Semi-colons are not allowed within a value; otherwise, two values will be created. 

Sample Express Structural Ontology Specifications 

An example of an express structural ontology specification 406 in spreadsheet form 804 
is shown in Figures 10A through 10N of incorporated provisional application no. 60/274,595, 
which show screen shots of sample pages from a such specification spreadsheet 804. For 
convenience, that example is also summarized textually below. 

The example is in a file named Promedix_Ontology_Spec.xls, in Microsoft Excel 
spreadsheet file format It includes a worksheet "Category Specification" with columns entitled 
"Category", "Search refinement page", and "Attribute display page", but in this instance all 
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other cells of the worksheet are empty. It also includes a worksheet "Attribute Specification" 

which has columns entitled "Category", "Category Expansion", "Category ID", "Family", 

"Family Attribute Name", "Search Method", "Field Name", "Data Type and Size", "PIMS 

mapping", and "Allowed values (for ENUMS)". In one instance, the first three columns 

contain data such as the following: 

Category Category Expansion 

Bottle ADHESIVES-Bottle 

Electromedical ADHESIVES~Electromedical 

Other ADHESIVES~Other 

Silicone ADHESIVES-Silicone 

Tapes ADHESIVES-Tapes 

ANTHROPOMETERS ANTHROPOMETERS 

ANTI-NAUSEA PRODUCTS ANTI-NAUSEA PRODUCTS 

ANTI-SLIP MATERIAL ANTI-SLIP MATERIAL 

ANTI-SNORE COLLARS/MASKS ANTI-SNORE COLLARS/MASKS 132000000000 

AROMATHERAPY AROMATHERAPY 143750000000 

ATOMIZER COOLING DEVICE ATOMIZER COOLING DEVICE 147750000000 



Category ID 

105640200000 

105640300000 

105640650000 

105640725000 

105640750000 

126300000000 

131600000000 

131960000000 



BACTERIA FILTERS 



BACTERIA FILTERS 



154520000000 



20 



25 



30 



FOOTPADS 

(SEE PADS, FOOT PADS) 



APPAREL-Footwear-FOOTPADS 137600050450 
APPAREL-Footwear- 137600050451 
FOOT PADS- 
(SEE PADS, FOOT PADS) 



Cells in the Family column contained question marks, or values such as "Anesth", "Apparel", 
"Services", "Lab"; the other cells in the worksheet were apparently empty. 

Promedix_Ontology_Spec.xls also includes a worksheet "FYI - Generic Attributes" 
with columns entitled "Search Method", "Field Name", "Data Type and Size", "PIMS 
mapping", and "Allowed values (for ENUMS)". In this instance, the Search Method cells and 
Allowed values cells are empty, and the other three columns' cells contain values such as the 





following: 
Field Name 


Data Tvoe and Size PIMS mapping 




category 


char(50) 




name 


char(500) 


35 


quantity 


number 




unitjnultiplier 


number(8) 




units 


char(20) 




price 


number(10,2) 




description 


CLOB 


40 


synonyms 


char(2000) 




applications 


char(4000) 




discipline 


char(500) 




additional_info 


chai(4000) 




references 


char(4000) 


45 


seals_ofapproval 


char(250) 
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certificate_of_analysis char(250) 



storagetemp 
shipping^temp 
related_products 
5 weight 
sku_id 

product id 

10 cmdxsku 

supplier_cat_num 
orig_mfg_catnum 

15 shipping^type 

review enum 



20 



25 



30 



35 



40 



45 



agency_enum 



char(500) 

char(500) 

char(500) 

number(15,5) 

numbei(12) 

number(12) 

char(250) 

char(40) 
char(64) 

number(5) 

number(5) 

number(5) 



regulatory_action_enum number(5) 
regulatory_schedule_enum number(5) 



MSDS 
image 

state enum 



barcode 

expiration_date 

UN_Number 

shippingjveight 



CLOB 
BLOB 

number(5) 



number(20) 
date 
number 
numer(15,5) 



CMDX internal sequence #, but possibly useful 
for you to store? 

CMDX internal sequence #, but possibly useful 
for you to store? 

CMDX internal, generated from other fields. 

Possibly useful for you to store? 

The VWR catalog number. Must be unique. 

Your original manufacturer's catalog number - 

your vendor cat num field. 

set of fixed values describing how a product is 

shipped (dry ice, etc). You may want to store. 

set of fixed values relating to regulatory review 

and control. You may want to store. 

set of fixed values relating to regulatory review 

and control. You may want to store. 

set of fixed values relating to regulatory review 

and control. You may want to store. 

set of fixed values relating to regulatory review 

and control. You may want to store. 

text only 

We accept jpgs and gife only. Need to be 
correlated to an individual product 
5 for all products not available via Labpoint but 
are needed in XRER 4 for all products available 
in Labpoint. 

NOT USED CURRENTLY 
NOT USED CURRENTLY 
NOT USED CURRENTLY 
NOT USED CURRENTLY 



Promedix_Ontology_Spec.xls also includes a worksheet "CHEMDEX Category 
Specification" with columns entitled "Category 5 ', "Search refinement page", and "Atribute 
display page", containing values such as those shown below; for clarity the string "Same as 
current Equipment* 9 used in the spreadsheet is indicated below by "ScE" and the string 
"Current generic + all family" used and highlighted in the spreadsheet is indicated below by 
"Cg+af": 

Category Search refinement pageAtribute display page 

Cleaning and Sterilization Instruments ScE ScE 

Accessories and Parts ScE ScE 

Other Instruments and Equipment ScE ScE 

Gloves Cg+af Cg+af 

Personal Protection Cg+af Cg+af 
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Safetv Products 


ScE 


ScE 


Ready-to-Use Gels and Columns 


Ce+af 

» ox 


Ce+af 

v'g » ax 


Filters and Membranes 


fV+af 


Pcr+af 


Glass-, Plastic- and other lab ware 


Ce+af 


Ce+af 


Other Lab Supplies 


Ce+af 


Ce+af 


Furniture and Office Sunnlies 






Books and Videos 


Cg+af 


Cg+af 


Software 


Cg+af 


Cg+af 


Services 


ScE 


ScE 
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8 new search pages 8 new product detail pages 

Promedix_Ontology_Spec jds also includes a worksheet "CHEMDEX Attribute 
Specification" with columns entitled "Category", "Faxriily Attribute", "Search Method", "Field 
Name", "Data Type and Size", 'TIMS mapping", and "Allowed values (for ENUMS)". A 
preface to the worksheet states the following in red letters: "All categories contain the current 
set of generic attributes as they currently exist (default_node_id = 1000), PLUS whaf s listed 
below". The initial Category cells contain values such as "Sensors, Analyzers and pH Meters", 
"Spectrometers", and "Balances", with corresponding Family Attribute cells containing 
"NONE" and the corresponding cells of other columns apparently empty. Then a row occurs 
with the following cell contents: 

Search Method 



Category 
Gloves 



Family Attribute 
Material 



Field Name 
material 



25 Data Type and Size PIMS mapping 
enum 



30 



35 



40 



45 



Allowed values (for ENUMS) 

latex = 1 

cotton = 2 

neoprene = 3 

silicone rubber = 4 

butyl synthetic rubber = 5 

rubber = 6 

vinyl = 7 

nitriie = 8 

PVA = 9 

PVC = 10 

viton =11 

hypalon= 12 

polyethylene = 13 

aramide = 14 

EVOH=15 

asbestos = 16 

leather =17 

nylon = 18 

wool = 19 

aluminium = 20 

Other = 50 
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The next two rows contain empty cells except as follows: 

Family Attribute Search Method Field Name Data Type and Size 
5 Sterile radio? sterile boolean 

Powder free radio? powder free boolean 

The subsequent rows contain additional values, including Family Attribute cell values such as 
"Pore size/MWCO", "Particle size", "Dimensions", "Number of wells", "Column type", 
10 "Compatibility", "Material", and "Sterile"; Search Method cell values such as "radio?", "text 
box", and "drop-down"; Field Name cell values such as "pore_size_MWCO", "particlejsize", 
"dimensions", c< number_ofwells", "column Jype", "compatibility", "material", and "sterile"; 
and Data Type and Size cell values such as "char(250)", "char(500)", "number(3)", "boolean", 
and "enum". 

15 The preceding is merely one example. Other express structural ontology specifications 

may differ from this example in various ways. As an example, some columns may be omitted 
and/or others added. If only one search method is used, no column of cells specifying different 
search methods would be needed. Field name and Family attribute could be combined into a 
single column in some specifications. The strings used to represent column names and cell 

20 values could vary. The data types and sizes available may vary. Mappings to database fields 
might be implicit in field names, or might be omitted if the specification is not used to generate 
data load scripts. Columns may be organized into worksheets differently; another specification 
includes only a Category Specification worksheet with columns entitled "Category", "Search 
refinement page", and "Atribute display page" plus an Attribute Specification worksheet with 

25 columns entitled "Family Attribute", "Search method", "Field Name", "Data Type", "PIMS 
mapping", and "Allowed values (for ENUMS)". Those of skill in the art will recognize that 
combinations of these and other variations are possible in different embodiments of the 
invention, given the teachings of the entire application and the knowledge brought to them by 
such persons. In one embodiment, the express structural ontology specification 406 includes a 

30 "required fields" identification, which is used for instance by the group of people who are 
responsible for configuring data tools 818 such as the web catalog manager 900. In one 
embodiment, the specification 406 includes a "printfile" identification, which is used for 
instance to create 506 print modules and QA modules. 

Another example of an express structural ontology specification 406 in spreadsheet 

35 form 804 is given in incorporated provisional application no. 60/280,1 96 at pages 49-5 1 . For 
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convenience, that example is also provided below. This ontology specification 406 was 

apparently used to generate output files shown in that incorporated application. In text format, 

the ontology data in the specification 406 includes the following excerpts: 

CATEGORY prod_att_def_iddef ault_node_idprint fileFamily 
Attribute : Search method Field NameDataType PIMS mapping 

Required? Website Category Name Allowed values (for 
ENUMS) 

Piping Valve-Ball 1057 1085 PVBALL Type: drop-down 

type enum-varchar2 (50) PROD_GA50X1 N One 
Piece Body; Two Piece Body; Three Piece Body; Three Way Split 
Body; Other 

Size (Inches) : drop-down size enum- 
varchar2(50) PROD_GA50X2 N 0.125; 0.25; 0.375; 

0.5; 0.75; 1; 1.25; 1.5; 2; 2.5; 3; 4; 5; 6; 8; 10; 12; 14; 16; 
18; 20; 24; 30; 36; Other 

Manufacturer: drop-down manufacturer 
enum-varchar2 (50) PROD_GA50X3 N APOLLO; 
ASASHI; ATOMAC; CHEMTROL; COOPER; DIXON; DRAGON; DRESSER; 
DURCO; KITZ; KTM; MCCANNA; MILWAUKEE; NELES- JAMESBURY ; POWELL; 
VELAN; VICTAULIC; VOGT; WATTS; WKM; OTHER 

Connection: drop-down connectionenum- 
varchar2(50) PROD_GA50X4 N Butt Weld (BW) ; Flanged 

(FLG); Socket Weld (SW) ; Sweat; Threaded (THD) ; Threaded X 
Socket Weld ; Other 

Insulation Type: drop-down 
insulation_typeenum-varchar2 (50) PROD_GA50X3 N 
Bare; THW; THHN; THWN; XHHW; RHH; RHW; TFFN; TF; TFF; AWM; 

MTW/AWM; ACTHH; HCFC; ACT (Bare) ; SDT/TC; XLP; EPR; FR-PVC; 

Polyethylene; PVC; Polypropylene; Teflon; Other 

Conductor Groupings : drop-down 
conductor_groupings enum-varchar2 (50) PROD_GA50X4 N 
Single; Pair; Triad; Other 

"No. of Conductors, Pairs , Triads:" drop- 
down number_of_conductorsenum-varchar2 (50) PROD_GA50X5 N 

1; 2; 3; 4; 5; 6; 7; 8; 9; 10; 11; 12; 13; 15; 16; 
17; 18; 19; 24; 25; 27; 36; 49; 50; 51; 102; Other 

Conductor Size: drop-down conductor_size 
enum-varchar2 (50) PROD_GA50X6 N 22; 20; 18; 

16; 14; 12; 10; 8; 6; 4; 2; 1; 1/0; 2/0; 3/0; 4/0; 250; 350; 
500; 600; 750; 1000; Other 

Color: drop-down color enum- 
varchar2(50) PROD_GA50X7 N Black; White; Red; 

Blue; Yellow; Green; Orange; Brown; Purple; Gray; Blk/Wht; 
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Strand: drop-down strand enum- 
varchar2(50) PROD_GA50X8 N Solid; Stranded; Other 

5 

Metallurgy: drop-down metallurgyenum- 
varchar2(50) PROD_GA50X9 N Copper; Aluminum; Other 

Armor: drop-down armor enum- 
10 varchar2(50) PROD_GA50X10 N None; Aluminum; 

Galvanized Steel; Other 

Jacket: drop-down jacket enum- 
varchar2(50) PROD_GA50X11 N None; Chrome PVC; Std 

15 PVC; Other 

' Tray Rated? radio tray_ratedboolean- 
char(l) PR0D_GA1X7N 

Shield: drop-down shield enum- 
20 varchar2(50) PROD_GA50X12 N Unshielded; Overall 

Shield; Individual Shield; Overall and Individual; Other 

Wire and Cable - Accessories 1325 1353 CABLEACC Type: 
drop-down type enum-varchar2 (50) PROD_GA50X1 N 
25 Cable Clips; Cable Cutters; Cable Pullers; Cable Tie 

Wraps; Crimp Tools; Fish Tapes; Heat Shrink Tubing; Pulling 
Grips; Pulling Line; Spiral Wrap; Electrical Tape; Wire Labels; 
Wire Lubrication; Wire Strippers; Other 

30 Wireway 1326 1354 WIREWAY Type: drop-down type enum- 

varchar2(50) PROD_GA50X1 N Wireway; Slotted 

Raceway; Adapter; Connector; Cover; Cross; Elbow45; Elbow90; 
Hanger; Reducer; Tee; Other 

35 Material: drop-down material enum- 

varchar2(50) PROD_GA50X2 N Metal; PVC; Other 

Width (Inches) : drop-down width enum- 
varchar2(50) PROD_GA50X3 N 1; 1,5; 2; 3; 4; 6; 8; 

40 Other 

Depth (Inches) : drop-down depth enum- 
varchar2(50) PROD_GA50X4 N 1; 1.5; 2; 3; 4; 6; 8; 

Other 

Length (Feet) : drop-down length enum- 
45 varchar2(50) PROD_GA50X5 N 1; 2; 3; 4; 5; 6; 10; 

Other 

Electrical - Other 1327 1355 ELOTHER Type: drop-down 
type enum-varchar2 (50) PROD_GA50X1 N Other 

50 
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A Sample User Interface Configuration File 

One embodiment of the invention generates 700-710 an ontology .properties file which 
includes the content shown below; for conciseness, material similar to mat shown was omitted 
at the points indicated by ellipses and some blank lines were removed. Similar examples are 
5 provided in incorporated provisional application 60/280,196 at pages 3 1-33 and61-63: 

# The Category ID "0" is reserved for the Generic Attributes 

CSEARCH0=Generic 
CMDISP0= 
10 CRDISP0= 

TTL_CATEGORffiS=22 

# Category names for search and display on the UI 

15 

CSEARCHl=Alkaline Batteries 
CMDISPl=Alkaline Batteries 
CRDISPl=Alkaline Batteries 
CORDER=l 

20 

CSEARCH2=Desk Staplers 
CMDISP2=Desk Staplers 
CRDISP2=Desk Staplers 
CORDER=2 



CSEARCH22=Paper Clips 
CMDISP22=Paper Clips 
30 CRDISP22=Paper Clips 
CORDER=22 

# All the Attributes for the above Categories 

# First the Generic attributes 

35 

VAR0A0= 
DISP0A0= 
ZONE0A0= 
PIMS0A0=prod_name 
40 ISSEARCH0A0=false 
FORMTYPE0A0= 

VAR0A1= 

DISP0Al=Description 
45 ZONE0Al= 

PIMS0A1 =product_description 

ISSEARCH0Al=false 

FORMTYPE0Al= 
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VAR0A2= 
DISP0A2=Supplier 
ZONE0A2= 
5 PIMS0A2=supplier_short_name 
ISSEARCH0A2=false 
FORMTYPE0A2= 

VAR0A3= 
10 DISP0A3=Supplier Catalog # 
ZONE0A3= 

PIMS0A3=supplier_cat_num 
ISSEARCH0A3=false 
FORMTYPE0A3 = 



VAR0A17= 
DISP0A17= 
20 ZONE0A17= 

PIMS0A1 7=supplier_id 
ISSEARCH0A17=false 
FORMTYPE0A1 7= 

25 TTL0=18 

# Now the category specific attributes 

#1 Alkaline Batteries 

30 

. VARlAO=size 
DISPlAO=Size 
ZONElA0=size 
ISSEARCHlAO=true 
35 FORMTYPElA0=enum 

VARlAl=mercuryFree 
DISP1 Al=Mercury Free? 
ZONE 1 A 1 =mercury free 
40 ISSEARCHlAl=true 
FORMTYPElAl=radio 

TTL1=2 

45 #2 Desk Staplers 

VAR2A0=coIor 
DISP2A0=Color 
ZONE2A0=color 
50 ISSEARCH2A0=true 
FORMTYPE2A0=text 
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VAR2Al=stapleType 
DISP2Al=Staple Type 
ZONE2Al=staple_type 
5 ISSEARCH2Al=true 
FORMTYPE2 A 1 =enum 

VAR2A2=paperCapacity 
DISP2A2=Paper Capacity 
10 ZONE2A2=paper_capacity 
ISSEARCH2A2=true 
FORMTYPE2A2=text 

TTL2=3 

15 



#22 Paper Clips 

20 VAR22A0=size 
DISP22A0=Size 
ZONE22A0=size 
IS SEARCH22 AO=true 
FORMTYPE22A0=enum 

25 

VAR22Al=material 
DISP22Al=Material 
ZONE22Al=material 
ISSEARCH22Al=true 
30 FORMTYPE22Al=enum 

VAR22A2=eolor 
DISP22A2=Color/Finish 
ZONE22A2=color 
35 IS SEARCH22 A2=true 
FORMTYPE22A2=text 

TTL22=3 

40 20 

A Sample Catalog Enumeration Load Sheet 

One embodiment of the invention generates 714 a generic attributes enum load file. The 

data in the load file is generated in the following format: 

45 , PIMS , | , 1023 , | , PP v OD_GA50Xl , |7| , Neomycin , ; 

where PIMS stands for the project name, 1013 stands for the Prod_Att_Def_Id, 

PROD GA50X1 is the actual column name, 7 is an example of the enumeration value, it could 

be any numeric number, and the last entry is the actual value (human-oriented representation). 
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One enum table includes an entry set that can map from default_node_id to 
prod_attr_defJd codes; an entry set that can map from default_node_id to visual 
representation; and an entry set that can map from prod_attr_defjd to visual representation. 

A Sample Checklist 

Figures 9A and 9B of incorporated provisional application no. 60/274,595 show an 
example from a checklist generated 718 in spreadsheet form from an express structural 
ontology specification 406. For convenience, that example is also described here. The checklist 
file contains a single worksheet, called "checklist". An initial part of the worksheet contains 
four named columns, including an empty "Comments" column and three columns containing 
values such as the following: 

Category Name Spelling correct? Format correct? 

Respiratory Therapy yes no yes no 

Plastics yes no yes no 

Nutrition and Dietary Supplies yes no yes no 

Veterinary Supplies and Equipment yes no yes no 

Subsequent rows ask "Are the categories in the correct order of appearance? yes no", and "Is 
the list of categories complete? yes no". This is followed by "Category names are spelled 
correctly, are properly formatted and are in the correct order on the Category Search Page". 

A next portion, "QA of Category Search Pages by Family", contains columns named 
"Category Name", "Attribute Name", "Correct?", "Search type", "Correct", "Allow enum 
values", "Correct?", and "Comments". Within these columns the categories and attributes of 
the marketplace (as extracted from the specification 406) are listed for review. For instance, a 
Category Name "Respiratory Therapy" has associated rows with Attribute Name cell values 
such as "respiratoryjype" and "mdi_field_l", with Search type cell values "drop-down" and 
"none", and with an Allow enum values cell containing "Aerosol Therapy/Treatment Devices; 
Air Compressors and Pumps; Air Oxygen Mixers, Concentrators, Purifiers, Cleaners, and 
Analyzers; Airway Kits; Blood Gas Sampling Equipment and Supplies; Breathing Aids and 
Exercisers; Filters, Moisture Traps; Gas Monitoring Equipment; Gases, Regulators, 
Cylinders and Accessories; Humidifiers; Iron Lungs; Other, Oxygen Masks and Delivery 
Devices; Percussors; Pulmonary Function Testing Devices-Peak Flowmeters, Volumeters, 
Spirometers; Respirators and Ventilators and Accessories; Vaporizers". Cells at the end of the 
Respiratory Therapy section ask "Attribute list complete? yes no" and "Enum lists complete 
yes no", so the person inspecting the attributes and enumeration values can circle "yes" or 
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"no" accordingly. Similar sections are provided for other Category Names. Other examples are 
provided in incorporated provisional application 60/280,196 at pages 26-28 and 67-68. 



Additional Examples and Details 

5 File naming conventions may be used. For instance, the PROD_ATTJDEF output files 

created by an inventive script 414 may be named according to the format <three-character 
alphabetic vertical code>_load_setup_<NN>.txt Various delimiter characters may be used 
between parameters in the script command line, with a blank space preferred. One file naming 
convention for output files created by inventive scripts 414 has the vertical company name, 
10 then an underbar, then the type of printfile, then another underbar, and finally the ".out" 
filename extension. 

In one embodiment, temporary files used by a script according to the invention are 
placed in a directory; files are organized according to families. For instance, a generated 712, 
716 Acmotor.txt file contains the following excerpt: 

15 

type|char|50||Squirrel Cage Induction Motor;Synchronous Motor,Other|prod_ga50xl 
speeds|char|50||Single Speed;Two Speed;Other[prod_ga50x2 

enclosure|char|50||TEFC;Explosion Proof (FCXP);Drip Proof (DP);Open;Otherjprod_ga50x3 

voltage|char|50||460Volts;115/230V;190/380V;200V^00/400V;230/460V^08- 
20 230/460;Other|prod_ga50x4 

phase|char|50|)Single Phase, Capacitor Start;Single Phase, Split Phase;Three 

Phase;Olher|prodjga50x5 

frequency|char|50||60;50;Other|prod_ga50x6 

service Jactor|char|50)| 1.15 ; 1 .0;Other|prod _ga50x7 
25 hp|char|50||0.5;0.75;l;1.5;2;3;5;7.^^ 

od _ga50x8 

rpm|chaii50||3600;18()0;12()0;900;Other|prod^0x9 

In general, the invention may be implemented in various ways using various data 

30 formats. For instance, one implementation might store generated 712, 716 data such as that just 

illustrated for Acmotor.txt in a spreadsheet file (e.g., Acmotor.xls) rather than (or in addition 

to) storing that data in a text file. 

A script 414 may be used to create other scripts 414, 808. For instance, in one 

embodiment scripts are created 726 by giving the following command: 

35 autoJcsh "family name" "defeult node id" "product att def id" 

where an example of a 'family name" is "bolts" an example of a "default node id" is 

"1031", and an example of a "product att def id" is "1456". 

One previously internal document describing a vertical generation script 414 according 

to the invention for use on a UNIX system, such as a UNIX Solaris system, includes the text 
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shown below [reference numbers have been added for convenience]; a shorter version of this 
document is also recited in incorporated provisional application 60/278,558 at pages 5-9: 



How do you use the scripts 

The main menu, menu_vertical.ksh, calls the vertical generating perl scripts which are in 
/CES/users/sma/verticals_build directory. You can cvs check out the scripts from directory 
ces/ventro/scripts/pims_l_7, and point BuildOut link to the directory you checked out 

1 . 1 . Following steps show you how to create an alias in your .cshrc file for easy access the 

menu_vertical.ksh script 
a), vi .cshrc 

b). add the line "alias BuildOut /CES/users/sxna/verticals^buUd/menu vertical.ksh" 
c). or instead of doing step 2, you can create a BuildOut alias to the directory where the perl 
scripts are cvs checked out to. 

d) . source .cshrc (now BuildOut will associate with the path of perl scripts, you can 
type in the alias and the script will be called correctly. 

e) . you can now start your vertical BuildOut script. 

Save the ontology file as a text file 

1 . create a new directory using Unix command- mkdir $ verticalName, SverticalName 
can be marketmile,promedix and etc 

2. change permission of the directory to 775 (chmod 775 SverticalName) 

3. rename the ontology file as tab-delimited file with the extension .txt and save it 
under the SverticalName directory. 

4. modify the tab-delimited file and delete all the headings from the files, (because 
each vertical may add different headings in the ontology file, the perl script can not 
catch all the exception). Save the modified file. 

e). You can run the BuildOut from any directory you want 

How to run BuildOut script 

a) If the ontology file named "Svertical.txt" is under the directory TestVerticals, you 
can use this ontology file as the source file to build out all the data load files and 
perl scripts for the Svertical. 

b) There are 2 types of choices. You can build out [506] individual files or scripts by 
choose one of the number from the Menu lists. Or, you can choose number 14 
which builds out [506] the entire vertical suites. 

c) You need to give the absolute directory path where the tab-delimited ontology file 
located, and give the file name as well. (Remember to remove the headings from 
the tab-delimited file before running the BuildOut) 

d) After finishing the BuildOut script, a report file in the same directory as ontology 
file is generated which briefly explains you what the files are. 

Run BuildOut 



-/TestVerticals > BuildOut 
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Menu lists 

1. Convert ontology txt file to flat txt file 

2. Generate enum data file from ontology spec sheet [406] 

3. Generate [714] qa tags from ontology spec sheet [406] 

4. Generate UI validation file from ontology spec sheet 
[406] 

5. Generate [716] data files for prod_tree_def and 
prod_att_def tables 

6. Generate printfile modules from ontology spec sheet 

7. Generate [726] parsing template from ontology spec 
sheet 

8. Generate Excel spread sheets from ontology spec sheet 

9. Generate create_new_company. ksh 

10. Generate [726] tab2pipeTemplate.pl 
14. Create verticals 

Please choose one of the above number [-1] : 
14 

Please enter absolute directory path of the ontology file 
: /CES/users/sma/TestVerticals 

Enter the name of the ontology text file [] : mmi.txt 

Directory /CES/users/sma/TestVerticals 

Spec sheet file name mmi.txt 

Output file name 

Option Build up [506] all enum files, qa 

tags, UI validation file, data input files for 
prod_tree_def , data file for prod_att_def tables, print 
modules, standard parsing script, excel files for DBA 
shares 

Are they correct [y] ? y 

sma@indy:~/TestVerticals > Is -ltr 
total 296 



-rwxr-xr-x 


1 sraa 


staff 


13072 


Oct 


9 


11:39 


mmi.txt* 














drwxr-xr-x 


2 sma 


staff 


4096 


Oct 


11 


17:31 


all_tags/ 














-rw-r — r — 


1 sma 


staff 


5739 


Oct 


11 


17:37 


enumFile_for_ 


review. out 












-rw-r — r — 


1 sma 


staff 


3299 


Oct 


11 


17:37 


enumFile [712, 728] 












-rw-r — r — 


1 sma 


staff 


1739 


Oct 


11 


17:37 


resetArray_Vert ical . pm 


[726] 










-rwxr-xr-x 


1 sma 


staff 


11470 


Oct 


11 


17:37 


qaTemplate.pl* [724] 












-rw-r — r — 


1 sma 


staff 


562 


Oct 


11 


17:37 



prod_tree_def . out [712 and/or 728] 
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8719 
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Oct 


11 
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— rw— r — r — 1 sma staff 
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J. u u u 


Oct 


11 


17: 


17 
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-rwxr-xr-x 1 sma staff 


1175 


Oct 


11 


17: 
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new_companyTemplate. ksh* [726] 












15 


drwxr-xr-x 2 sma staff 


4096 


Oct 


11 


17: 
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Detail about the scripts and data files. 

20 

• Script: qaTemplate.pl 

• Purpose: The data files are pipe-delimited text files which are ready to load into databases 
by load scripts. Since the nature of data files is complicated, we like to ensure the data 

25 schema in the text files are correct before being loaded to production databases. The 

[generated 724] qa script, qaTemplate.pl, is designed to validate individual columns of data 
files to make sure the data types and values of the data load files are the same as defined by 
ontology. Data load files contain 2 major portions, the generic attributes and the family 
attributes. There are 44 generic attributes for PIMS 1.7 schema, and the numbers of family 

30 attributes are vertical dependent. The number of generic attributes can be updated 
according to the different versions of PIMS. 

• QaTemplate.pl reads tag files under alltags directory: Before building qaTemplate.pl, 
the tagj5enerat0r.pl gets called first to build all the tag files based on ontology file and 

35 stored them under the all Jags directory. The tag files have names with Sprintfile.txt which 
will be used for matching data files during qa. 

• How to modify the qaTemplate.pl script: 

40 Before running qaTemplate.pl, you need to modify the following items. 
Note 1: 

(Required) you need to update the SqaDir to where die qaTemplate.pl script is created. 

45 

my SqaDir = 7CES/users/<ehangeme>"; 

e.g. If the qaTemplate.pl was created under /CES/users/sma/marketmile/verticals, 
then the SqaDir will be 

50 

SqaDir = "/CES/users/sma/marketmile/verticals 55 ; 

45 



WO 02/073493 



PCT/US01/25468 



Note 2: 

(Optional) I suggest to rename qaTemplate.pl as qa$Vertical.pl, it will help you identify 
different tag sources for qaTemplate.pl. 

e.g. mv qaTemplate.pl qaMmi.pl (for $Vertical name as Mmi) 

Note 3: 

(Optional) Create an alias in your login .cshrc file which allows easy access of qa 
script 

alias qaMmi.pl /CES/users/sma/marketmile/verticals/qaMMI.pl 

Note 4: 

(Optional) You can cd to the directory where the data files are, and run the following 
command. 

Usages: qaMmi.pl <company name> . /*out 
|<- $ARGV[0]--->| 

Note 5: 

The qaTemplate.pl reads and extracts the $printfile names from all the data load files 
provided by $ARGV[0]. It is important to have $printfile in the tag files match 
$printfile in the data load files. If the spelling of data files don't have correct $printfile 
as provided in ontology, qaTemplate.pl will fail to qa the data files. 

After matching the data load files with one of the tag files, qaTemplate.pl compares 
both generic and family attributes in the data files with both generic.txt and the chosen 
tag file. The generic.txt is common across all the verticals which describes the schema 
of data types, allow values and required-or-not of all the generic attributes. Family tag 
files contains the data schema of the family attributes only. 

e.g. The qaTemplate.pl extracts $printfile names from data files 

if ($infile =~ AQ$companyName\E\J?(.+)Vout/) { 

$family = $l; 

// $1 contains the $printfile which is shortname for the $family 



} 

e.g. The qaTemplate.pl extracts $printfile names from tag files to build hash 
%wantedTagHash 

foreach StagFileName (@tagFiles) { 
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open (TAG, StagFileName) || die "Cant open StagFileName $! \n"; 
StagFileName =~ s/.+V( *?)\.txt/$l/i; 



5 $wantedTagsHash{$tagFileName} {"columnQ"} = $line; 

} 

• Script: tab2pipe.pl 

10 Usages: tab2pipe.pl <source directory> <new directory> 

Purpose: [Generated 726] tab2pipe.pl is to convert tab-delimited files with pipe delimiter, 
and the file can have extension txt, out, inp and ctl. 

Note 1: The script will convert the tab to pipe, and remove ctl M to replace it with a new 
15 line for all the files under the "source directory" and copy the edited files to a new 
directory. 

Note 2 : You need to provide the absolute paths of the source and new directories. 
20 Note 3 : The new directory will be created if it is not there previously. 

• Script: StandardjaringTemplate.pl 

• Purpose: This is a perl parsing script which calls print modules. It takes 6 steps to generate 
[726] the standardjparsingTemplate.pl 

25 

Step 1 : Saved the ontology file as text file. 
Step 2: merge.pl will merge the text file as a new input file. 
Step 3: buildjrintColumnCtHash.pl builds a "printfile hash" with $printfile as key, 
and list reference as values. The list contains total attribute counts, prod att def id, and 
30 default_node_id. 

Step 4: combineResetArray joins pimsColumnCt_table with resetArray.pm to form 
[726] vertical specific resetArray.pm. 

Step 5: parsingTemplate_l.pl and parsingTemplate_2.pl contain portions of 
parsingTemplate. 

35 Step 6: combineStdParsing.ksh joins both parsingTemplate together. 

Note 1 : This is a parsing template. The script calls the print module and you need to update all 
the <changeme>. 

40 • Script: tag_generatorTemplate.pl 

• Directory: all Jags 

Note 1 : The directory contains all the data files used by the qa scripts. It was generated by 
tag_generatorTemplate.pl 

45 
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Note 2: tag^generatorTemplatcpl reads in ontology flat file to build qa files from ontology 
spreadsheet. All the qa files are stored under "alltags" directory, and the qa files are 
named as $printfile.txt such as pipe.txt The format of the Sprintfile.txt is "SfamAtt 
|$dataType |$dbSize |$require |$allowValue |$pimsType &&&&". The qaTemplate.pl 
5 reads in the qa files and parses the values with pipe-delimiter. After comparing the data 
load files again their corresponding qa files, the script will report errors in genericError file. 

• Script: mapExcelfile.pl 

10 Purpose: to build [712] femily attribute excel spreadsheets and node.ga files from ontology 
spreadsheet. 

Note 1 : The mapExcelfile.pl reads ontology data and generic.txt to build 2 hash tables 
including the generic hash and family hash. Generic hash contains all the common generic 
15 attributes, and family hash contains the family attributes described in ontology spec sheet 

• Directory: familyAttribute 

Note 1: The directory contains all the Excel spread sheets used by Database 
20 engineering team to create vertical specific schema. 

• Directory: node^ga 

Notel: [generated 712, 714] nodejd.ga file, used by DBA team to create [726] data 
25 load files 

• File: reporttxt 

Note 1 : The file contains the paths of the new files generated by menuverticaLksh 



30 



35 



• Script: validate.pl 

Purpose: validate.pl reads familyattributes, search_type and allowed_values from ontology 
spec sheet to build [718-722] a checklist in Excel format. The checkListxls is used for front 
end UI display. 



• File: checkListxls 

Note 1 : The file contains the checklist of the [generated 720-722] front end values. 

40 • Files: enumFile and enumFile_forjeview.txt 

Note 1 : enumFile is [generated 712, 728] for DBA load to enum table 
Note 2: enumFUejfor_review.txt is for content QA do the data review 

45 • File: prod_att_def.out 

Note 1 : [Generated 712, 728] For DBA to populate prod_att_def table 

• File: prod_tree_def.out 



50 



48 



WO 02/073493 PCT/USO 1/25468 

Notel : [Generated 712, 728] For DBA to populate prodJree_def table. 

• File: ontology .properties 

5 Notel: For front end to use. It is B20 compatible. 

• File: Enum.properties 

Notel : For front end enum get service. It is B20 compatible. 

10 

• Script: resetArrayTemplate.pm 

• Purpose: To reset the generic and family arrays to values null. 

• Note 1: combineResetArray.ksh joins lines 1-36 of resetArrayTemplate.pm, with 

15 • Note 2: script build_printColumnCtHash.pl creates "printfile" as a key and 3 values as 
hash values. The values are total column counts, prod_att_def_id, and default jnode_id. 

"ADAPTER" => [46,1026,1054], 
"BEND" => [45,1027,1055], 
20 "BOLT" => [45,1023,1051], 

• Script: familyAttjTemplate.pl 

Purpose: familyAtt_Template.pl reads prod_att_def Jid and default_node_id columns 
25 from ontology spec sheet, and generates two files including "prod_tree__def.ouf ' 

and "load_setup.ouf\ ProdJxee_def.out is used by DBE to populate prodjtreejdef 
table, and the data is required for database build out. Load_setup.out is used by 
DBE to create [726] automated data load scripts. 

30 In one embodiment, a menu_vertical.ksh file contains text such as the following: 

#!/usr/bin/sh -f 

jjj;*******************************^ 

35 # Name: 

• vertical. sh 
# 

• Purpose: 
# 

40 # Usage: 

• Run this script by typing vertical. sh 
# 

45 unalias cd 
unalias rm 
unalias cp 

bold= x tput smso N 
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offbold= s tput rmso x 

confirm="n" 

PROJECT_DIR="/CES/users/sma/vertical_buildPIMS17 ,f ; 

while [ "^confirm" !=""]&&[ "$confirm" != "y" ] 
do 



10 clear 
echo 



echo "| |" 
15 echo " | Vertical menus I " 

echo "| I" 
echo 

»+===============^=====================-=========-===========+" 



20 echo " 
echo " 



echo " " 
echo " " 



input 

while [ "$input" = ] 
do 

0PTI0N_FLAG=-1; export OPTION_FLAG 



clear 
echo " " 
echo " " 

echo " Menu lists" 
35 echo " " 

echo " " 

echo "1. Convert ontology txt file to flat txt file" 
echo "" 

40 echo "2. Generate enum data file from ontology spec 

sheet" 

echo "" 

echo "3. Generate qa tags from ontology spec sheet" 
echo "" 

45 echo "4. Generate Ul validation file from ontology spec 

sheet " 

echo " " 

echo "5. Generate [726] data files for prod_tree_def 
and prod_att_def tables, and load_setup . out for auto.ksh " 
50 echo " " 
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echo "6. Generate printfile modules from ontology spec 

sheet" 

echo " " 

echo "7. Generate parsing template from ontology spec 
sheet" 

echo " " 

echo "8. Generate Excel spread sheet s /node_id. ga files 
from ontology spec sheet" 
echo " " 

echo "9. Generate [726] create_new_company . ksh" 
echo " " 

echo "10. Generate tab2pipeTemplate.pl" 
echo " " 

echo "11. Generate ontology .properties" 
15 echo " " 

echo "14. Create verticals" 
echo " " 

echo "Please choose one of the above number 
20 [ $OPTION_FLAG] : \c" 
echo "" 



10 



read input 
if [ "$input" - "" ]; then 
25 input=$OPTION_FLAG 
f i 



if [ "$input" <> "" ]; then 

30 if [ "$input" - 1 ]; then 

ACTION="Convert ontology spec sheet to flat file" 
OPTION="l" 



elif [ "$input" = 2 ]; then 
35 ACTION="Generate enum file from ontology spec 

sheet" 

0PTI0N="2" 
elif [ "$input" = 3 ]; then 

ACTION="Generate qa tags from ontology spec sheet" 
40 OPTION="3" 



elif [ "$input" = 4 ]; then 

ACTION="Generate qa tags from ontology spec sheet" 
OPTION="4" 

elif [ "$input" = 5 ]; then 

ACTION="Generate prod_att_def and pord_tree_def 

files" 

0PTI0N="5" 

elif [ "$input" = 6 ]; then 
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ACTION="Generate print modules from ontology spec 

sheet" 

OPTION="6" 

5 elif [ "$input" = 7 ]; then 

ACTION="Generate a parsing template from ontology 

spec sheet" 

OPTION="7" 

10 elif [ "$input" = 8 ]; then 

ACTION="Generate Excel templates/node_id. ga from 
ontology spec sheet" 

OPTION="8" 

15 elif [ "$input" = 9 ]; then 

ACTION="Generate the create_new_company . ksh" 
OPTION="9" 

elif [ "$input" =10 ]; then 
20 ACTION="Generate the tab2pipe.pl" 

OPTION="10" 

elif [ "$input" - 11 ] ; then 

ACTION="Generate the ontology .properties" 
25 OPTION="ll" 

elif [ "$input" =14 ]; then 

ACTION="Build up all enum files, qa tags, UI 
validation file, data input files for prod_tree_def , data file 
30 for prod_att_de£ tables , print modules, standard parsing 
script, excel files for DBA shares" 
OPTION="14" 

fi 

35 fi 

done 

input="" 
40 while [ "$ input" = "" ] 

do 

echo "Please enter absolute directory path of the ontology 
file : \c" 

read input 

45 

if [ "$input" <> "" ]; then 
if [ -d $ input ] ; then 
TOP=$input; export TOP 
break 
50 else 

echo "'" $input " f is not a valid directory." 
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input="" 
echo " " 
fi 

fi 
done 

input="" 

if [ $0PTI0N ! = 9 ] ; then 

while [ "$input" = ] 
do 

echo "Enter the name of the ontology text file 
[$FILE_NAME] : \c" 
read input 

if [ "$input" = "" ]; then 
input=$ FI LE_NAME 

fi 

if [ "$input" <> ]; then 
if [ -r $TOP/$input ] 
then 

FILE_NAME=$ input; export FILE_NAME 

break 
else 

echo "'" $input is not a valid file or file is 
not readable . " 

echo "All data files must under TOP/data 

directory. " 

input=" " 
echo " " 
fi 

fi 
done 

fi 

if [ "$OPTION" != "3" ] && [ "$OPTION" != "5" ] && [ 
"$OPTION" != "7" ] && [ "$OPTION" != "8" ] && [ "$OPTION" != 
"7" ] && [ "$OPTION" != "6" ] && [ "$OPTION" != "14" ] && [ 
"$OPTION" .'= "9" ] && [ "$OPTION" != "10" ] && [ "$OPTION" ! = 
"11" ]; then 

input="" 

while [ "$ input" = "•• ] 
do 

echo "Enter the output file name [$FLAT_FILE] : \c" 
read input 

if [ "$input" = "" ] 

then 
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FLAT_FILE="flat_spec.txt"; export FLAT_FILE 

break 

fi 

5 if [ n $input" <> "" ] 

then 

echo "HI IN THE LINE 214 $input $FLAT_FILE" 
FLAT_FILE=$input 

fi 

10 done 
fi 

echo " " 
15 echo " " 

echo " " 
echo " " 

echo "Directory " $TOP 

20 echo "Spec sheet file name " $ FILENAME 

if [ "$OPTION" !- "3" ] && [ "$OPTION" != "5" ] && [ 
"$OPTION" != "6" ] && [ "$OPTION" != "7" ] [ "$OPTION" != 
"9" ] 

then 

25 echo "Output file name " $FLAT_FILE 

fi 

echo "Option " $ACTION 

echo "" 

30 echo "Are they correct [y]?\c" 
read confirm 
echo $confirm 

done 
35 echo " " 
echo " " 

if [ "$OPTION" - "1" ]; then 

$PROJECT__DIR/merge.pl $TOP $FILE_NAME $FLAT_FILE 

40 

elif [ "$OPTION" = "2" ]; then 

temp File=" tempflatfile.txt" 

$PROJECT_DIR/merge.pl $TOP $FILE_NAME $tempFile 

$PROJECT_DIR/enumTemplate.pl $TOP $tempFile $FLAT_FILE 
temp=" $ FLAT_FILE"_for_review 
echo "$temp" 

50 echo "File $bold $FLAT_FILE $offbold is enum load file 

which is in the $TOP directory" 
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echo " " 

echo "File $bold $temp $offbold is for review purpose" 
echo " " 

elif [ "$OPTION" = "3" ]; then 

tempFile-" tempflatfile.txt " 

$PROJECT_DIR/merge.pl $TOP $FILE_NAME $tempFile 

$ PRO JECT_DIR/t ag_generatorTemplate.pl $TOP $tempFile 

cp $PROJECT DIR/qaTemplate.pl $TOP 



echo "Outputs are in $bold $TOP/all_tags directory 
$offbold " 

echo "$bold qaTemplate is also copied to $TOP directory 
$offbold" 
15 echo " " 

elif [ "$OPTION" = "4" ]; then 

tempFile="tempf latfile.txt" 
20 $PROJECT_DIR/merge.pl $TOP $FILE_NAME $tempFile 

$PROJECT_DIR/validate.pl $T0P $tempFile $FLAT_FILE 
echo "" 

echo "UI validation file, $bold $T0P $ FLAT_FILE.xls 
25 $ off bold " 

echo " " 
echo " " 



elif [ "$0PTI0N" - "5" ]; then 

tempFile="tempf latf ile . txt " 

$PROJECT_DIR/merge.pl $TOP $FILE_NAME $tempFile 



$ PROJECT JDIR/f amilyAtt_Template.pl $TOP $tempFile 
35 echo "" 

echo "$bold $TOP/ prod_tree_def .out $offbold is generated 

it 

echo "$bold $TOP/prod_att_def . out $offbold is generated 

I? 

40 echo " " 

echo " " 

elif [ "$OPTION" = "6" ]; then 

## create the hash for family 
45 tempFile="tempf latfile.txt" 

$ PRO JECT_DIR/mer ge.pl $T0P $FILE_NAME $tempFile 
$PROJECT_DIR/build_jDrintColumnCtHash.pl $TOP $tempFile 

## join the printColumnHash with the printTemplate 
50 $PR0JECT_DIR/combinePrint4Pims. ksh $TOP pimsColumnCt_table 
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echo "$bold print4PIMS_vertical .pm is created $offbold 
under $TOP" 

elif [ "$OPTION" = "7" ]; then 
5 ## hash for each family has to be built out first, so we 

then know 

## how many column counts per family 

tempFile=" tempf latf ile . txt " 
10 $PROJECT_DIR/merge.pl $TOP $FILE_NAME $tempFile 

$ PRO JECT_DIR/buildjpr intColumnCtHash.pl $T0P $tempFile 

## create the resetArray_Vertical .pm in the same directory 
## join the hash value with the resetTemplate 



15 



$PROJECT_DIR/combineResetArray. ksh $TOP pimsColumnCt_ table 



## create the standard parsing template 
$PROJECT_DIR/parsingTemplate_l .pi $T0P 
20 $ PRO JECT_DIR/par singTemplate_2.pl $T0P $tempFile 

$ PRO JECT_DIR/combineStdPar sing, ksh $TOP 

elif [ "$0PTI0N" = "8" ]; then 
tempFile=" tempf latf ile. txt" 
25 $ PRO JECT_DIR/mer ge.pl $TOP $FILE_NAME $tempFile 

$PROJECT_DIR/mapExcelfile.pl $TOP $tempFile 
echo "excel files are created under $bold 
$TOP/family_Attbribue $offbold directory " 

echo "<N0DE_ID>.ga files are created under $bold 
30 $T0P/node_id $offbold directory " 

elif [ "$OPTION" = "9" ]; then 

echo "Create create_new_company . ksh" 

cp $PROJECT_DIR/new_companyTemplate. ksh $TOP 

35 

elif [ "$0PTI0N" = "10" ]; then 

echo "Create tab2pipeTemplate.pl" 

cp $ PRO JECT_DIR/t ab2pipeTemplate.pl $T0P 

40 elif [ "$0PTI0N" = "11" ]; then 
tempFile="tempf latf ile. txt" 

$ PRO JECT_DIR/mer ge.pl $TOP $FILE_NAME $tempFile 
$ PRO JECTJDIR/f rontEndProperty.pl $T0P $ FILENAME 
$PR0JECT_DIR/combineFrontEnd.ksh $T0P 
45 FE_property_family.txt FE_property_attribute.txt 

echo "excel ontology. properties file is created under $bold 
$TOP/ontology. properties $offbold directory " 

elif [ "$0PTI0N" - "14" ]; then 
50 tempFile="tempf latf ile. txt" 

$PR0JECT_DIR/merge.pl $T0P $FILE_NAME $tempFile 
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## create enum file 
FLAT_FILE=enumFile 

$PROJECTJDIR/enumTemplate.pl $TOP $tempFile $ FLAT_FILE 
## create qa scripts 

$PROJECT_DIR/tag_generatorTemplate.pl $TOP $tempFile 
cp $PROJECT_DIR/qaTemplate.pl $TOP 

## create validation file 
checkList= n checkList" 

$PROJECT_DIR/validate.pl $TOP $tempFile $checkList 

## create files for prod__tree_def and prod_att_def tables 
$ PRO JECT_DIR/f amilyAtt_Template.pl $TOP $tempFile 

## create print modules 

$ PRO JECT_DIR/buildjpr intColumnCtHash.pl $T0P $tempFile 
$PR0JECT_DIR/combinePrint4Pims. ksh $TOP pimsColumnCt_table 

## create standard parsing script 

$PROJECT_DIR/combineResetArray. ksh $TOP pimsColumnCt_table 
$PROJECT_DIR/parsingTemplate_l .pi $TOP 
$PROJECT_DIR/parsingTemplate_2.pl $TOP $tempFile 
$ PRO JECT_DIR/combineStdPar sing, ksh $TOP 

## create Excel spreadsheets 
$PROJECT_DIR/mapExcelf ile.pl $T0P $tempFile 

## copy tab2pipeTemplate.pl and new_companyTemplate . ksh 

cp $PROJECT_DIR/new_companyTemplate. ksh $T0P 
cp $PR0JECT_DIR/tab2pipeTemplate.pl $T0P 

## create front end ontology .properties 

$ PRO JECT_DIR/ front EndProperty.pl $T0P $tempFile 
$PROJECT_DIR/combineFrontEnd. ksh $T0P 
FE j?roperty_f amily . txt FE_property_attr ibute . txt 

## clean up the temp files 
*rm $TOP/templ_stdjparsing. txt x 
*rm $T0P/temp2_stdjpar sing, txt s 
N rm $TOP/tempflatfile.txt v 
v rm $TOP/pimsColumnCt_table K 

## generate a report 

echo " " > $TOP/report.txt 
echo " " » $TOP/report.txt 
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echo " Reports for the created files (PIMS 1.7) n 

» $TOP/report . txt 

echo " n » $TOP/report.txt 
echo " " » $TOP/report .txt ' 

echo "1. enumFile__for_review.out — > is the enum file for 
qa review\n" » $T0P/report .txt 

echo " " » $TOP/report . txt 
echo " " » $TOP/report.txt 

echo "2. enumFile — > is the enum file for loading to 
database\n\n" » $TOP/report . txt 
echo " " » $TOP/report.txt 
echo " " » $TOP/report.txt 

echo "3. prod_tree_def .out — > is the data file for 
loading to prod_tree_def table\n\n fr » $TOP/report. txt 
echo " " » $TOP/report.txt 

echo "4. prod_att_def .out — > is the data file for 
loading to prod_att_def table\n\n" » $TOP/report . txt 
echo "" » $TOP/report.txt 

echo "5a. Directory $TOP/all_tags contains all the 
configuration files for QA purpose\n\n" » $TOP/report . txt 

echo "5b. [generated 724] qaTemplate — > is the qa script, 
please remember to update the $qaDir in the qaTemplate\n\n" » 
$TOP/report .txt 

echo " " » $TOP/report.txt 

echo "6. UI validation file — > is a file used for front 
end validation" » $TOP/report . txt 
echo " " » $T0P/report . txt 

echo "7a. Standard_j?aringTemplate.pl — > the perl script 
is the Standard parsing template. Please remember to modify 
the script \n" » $TOP/report . txt 

echo "7b. There are 2 [generated 726] modules for the 
StandardjparsingTemplate.pl. — > resetArray_Vertical .pm and 
print4PIMS_vertical . pm\n\n" » $TOP/report . txt 

echo " " » $TOP/report.txt 

echo "8. Directory $TOP/f amily__Attribute contains all the 
Excel spreadsheets /NODE_GA for the ontology " » 
$TOP/report.txt 

echo "8. Directory $TOP/node_ga contains all the node.ga 
files for database loading " » $TOP/report . txt 

echo " " » $TOP/report.txt 

echo "9. Generate a shell script, new_companyTemplate. ksh" 
» $TOP/report.txt » $TOP/report . txt 
echo " n » $TOP/report . txt 

echo "10. Generate a perl script, tab2pipeTemplate.pl " » 
$TOP/report . txt 

echo " " » $TOP/report.txt 

echo "11a. Generate B20 ontology .properties which is used 
for front end UI display " » $T0P/report . txt 
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echo "lib. Generate B20 Enum. properties which is used for 
EnumGet service n » $TOP/report . txt 
echo " " » $TOP/report.txt 

5 

echo "Vertical files have been created, please read 
$T0P/report .txt to get detail information" 

fi 

10 

exit 0 



In one embodiment, a generated 726 load_setup.out file contains text such as the 

15 following excerpt: 

auto.ksh pvball 1085 1057 
auto.ksh pvbfly 1273 1246 
auto.ksh pvcheck 1274 1247 
auto.ksh pvdiaph 1275 1248 
20 auto.ksh pvgate 1276 1249 
auto.ksh pvglobe 1277 1250 
auto.ksh pvneedle 1278 1251 

A database group may use files "load_setup.out" and nodejga files *.ga and 

25 automatically create 726 database load scripts from the configuration files based on the 

ontology specification 406. In one embodiment, the auto.ksh file includes the following: 

#!/bin/ksh 

ORACLE_HOME=/opt/oracle/815 

TNS_ADMIN=/var/opt/oracle; export TNS_ADMIN 
30 PATH=/home/bpatel/db_eng/pimsl7/load/common/template: $ORACLE_HO 
ME/bin : /bin : /usr /bin : /etc; export PATH 

LD_L I BRARY_PATH= $ ORACLE_HOME /lib; export L D_L I BRAR Y_P AT H 

if [ $# -ne 7 ] 
35 then 

echo 

echo "USAGE: $0 <f amily><node_id> <att_def_id><db_name> 
<3 digit vertical code> <pims_load a/c password> <pims a/c 
password>" 

40 echo "FAMILY — > Name of the family ex. alk_bat" 

echo "NODE_ID — > Node ID as specified in 

prod_tree_def ex. 1120" 

echo " ATT_DE F_I D ~> Attribute definition id ex. 1101" 
echo "DB_NAME — > Name of the database in 

45 which data will be loaded" 
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echo "VERT — > Three digit Vertical code ex. cmd 

for chemdex" 

echo "PASSWORD_LOAD — > Password for the PIMS_LOAD 

account" 

5 echo "PASSWORD_PIMS — > Password for the PIMS 

account" 

echo 
exit -1 

else 

10 FAMILY= N echo $l|cut -cl-25 N 

NODE_ID=$2 

ATT_DEF_ID=$3 

DB_NAME=$4 

VERT=$5 
15 PASSWORD_LOAD=$ 6 

PASSW0RD_PIMS=$7 

fi 

C0MM0N_BASE=/home/bpatel/db_eng/pimsl7/load/common/template 
VERT_BASE=/home /bpate 1 /ve rt_loads /pirns 1 7 /$ VERT 
20 cd $VERT_BASE/tmp 

# Creating the GA attributes line here 

sed s/" "//g $VERT_BASE/ga/$NODEJCD.ga >att_def02 
awk -f $COMMON_BASE/corabine.awk att_def02 >att_def03 
25 awk -f $COMMON_BASE/combine_val.awk att_def02 >att_def_val03 
rm att_def02 

# Creating GA attribute description here 
sqlplus -s pims/$PASSWORD_PIMS@$DB_NAME 

30 @$COMMON_BASE/get_ga_desc.sql $ATT__DEF_ID 
sed /SQL/d att_desc.lst >att_desc01 
sed /:/d att_desc*lst >att_desc01 
sed s/" n //g att_desc01 >att_desc02 

awk ~f $COMMON_BASE/combine.awk att_desc02 >att_desc03 
35 sed s/NOTNULL/"NOT NULL"/g att_desc03 >att_desc04 
rm att_desc.lst att_desc01 att_desc02 att_desc03 

# Creating the loader file here 

sed s / ADD_TEMPLATE_HERE / $ FAMILY /g $COMMON_BASE/load_template . sh 
40 >. . /loader/load_$FAMILY. sh 

chmod 755 . ./loader/load_$FAMILY.sh 

# Creating the loader control file here 

sed s / ADD__TEMPLATE__HERE / $ FAMILY /g $COMMON_BASE/template. ctl 
45 >$ FAMILY. ctl 

GA_LINE= x cat att_def03 % 

sed s/ADD_GA_HERE/$GA_LINE/g $ FAMILY, ctl >. . /ctl/$FAMILY. ctl 
rm $ FAMILY. ctl 

50 # Creating Table file here 
GA LINE= * cat att desc04 v 
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sed s/ADD_TEMPLATE_HERE/$FAMILY/g $COMMON_BASE/template . sql 
>tab01.sql 

sed s/ADD_GA_HERE/ f, $GA_LINE"/g tabOl.sql >. . /table/ $FAMILY. sql 
sqlplus -s pims_load/$PASSWORD_LOAD@$DB_NAME 
5 @ $ VERT JBASE/table/$ FAMILY, sql 
nti tabOl.sql 

# Creating mapping function here 
GA_DEF= v cat att_def03 % 

10 GA_VAL= * cat att_def_val03 v 

sed s/ADDJTEMPLATE_HERE/$FAMILY/g $COMMON_BASE/map_template . sql 
>map01.sql 

sed s/ADD_ATT_VAL_HERE/$ATTJ)EF_ID/g mapOl.sql >map02 v sql 
sed s/ADD_NODE_VAL_HERE/$NODE_ID/g map02.sql >map03.sql 
15 sed s/ADD_PROD_GA_HERE/"$GA_DEF"/g map03.sql >map04.sql 
sed s/ADD_PROD_GA_VAL_HERE/ n $GA_VAL"/g map04.sql 
> . . /map /map_$ FAMILY . sql 

sqlplus -s pims_load/$PASSWORD_LOAD@$DB_NAME 
@$VERT_BASE/map/map_$ FAMILY . sql 
20 rm mapOl.sql raap02.sql map03.sql map04.sql 

# Done creating all files, Removing the junk 
rm att_def03 att_def_val03 att_desc04 

25 In one embodiment, a generated 71 2, 714 .ga file contains the following: 

PROD_GA50X1 

PROD_GA50X2 

PROD_GA50X3 

PROD_GA50X4 
30 PROD_GA50X5 

PROD_GA50X6 

PROD_GAlX7 

PROD_GAlX8 

PROD_GAlX9 
35 PROD_GA50X7 

PRODJ3A1X10 

In one embodiment, the load-setup.out is a shell script file generated 506 using the 
vertical buildout scripts, which the DBA runs to create the data loading scripts used by the 
40 marketplace. This script uses the .ga files and a DBA-created script called auto.ksh to 

automatically generate 506 the ontology-specific data load scripts for a marketplace. It is a 
script that uses config files and a generic set of scripts to create customized scripts for data 
loading. 

In one embodiment, each line of the load_setup.out shell script builds a different 
45 family-specific data load script 

One embodiment includes one .ga file per product family. 
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In one embodiment, a combine.awk file referenced by auto.ksh includes: 

{cmd=cmd "," $0} 
END {print cmd} 

5 In one embodiment, a combine vaLawk file referenced by auto.ksh includes: 

{ cmd=cmd " , l_record . " $0 } 
END {print cmd} 

In one embodiment, a get^jjadesc.sql file referenced by autaksh includes: 

10 

SET NEWPAGE 0 
SET TAB OFF 
SET SPACE 0 
SET LINESIZE 132 
15 SET PAGESIZE 0 
SET. ECHO OFF 
SET FEEDBACK OFF 
SET HEADING OFF 
spool att_desc 

20 select COL_NAME| | '■ varchar2 ( » | | to_char (data_size) | | 1 ) 
1 | | decode (required, 'Y', 'NOT NULL', 'NULL') from 
prod_att_def 

where prod_att_def_id=&l 

and COLJJAME not in ( 
25 ' ' PROD_GA500X1', 

f PROD_GA500X2\ 

'PROD_GA500X3', 

1 PR0D_GA1X1 ■ , 

1 PROD_GAlX2 1 , 
30 ' PROD_GAlX3 1 ,• 

, PROD_GA500X4 , f 

'PROD_GA250X1', 

' PRODJ3A1X4 1 , 

' PROD_GA250X2 ? , 
35 1 PROD_GAlX5 1 , 

' PROD_GA1X20', 

, PROD_GAlX6 f ) ; 

spool off 

exit 

40 

In one embodiment, a loadjemplate.sh file referenced by auto.ksh includes: 

# ! /usr/bin/sh 
unalias cp 
unalias rm 
45 unalias mv 

echo " Please wait; processing ADDJTEMPLATE_HERE" 

LOG=$TOP/log/load_$LOG_NAME N date +%m%d%y v - log; export LOG 
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SQL_LOG=$TOP/log/sqlloader_$LOG_NAME x date +%m%d%y x . log; export 
SQL_LOG 

BADJ)ATA=$TOP/bad/sqlloader_$LOGJ*AME x date +%m%d%y % .bad; export 
BAD__DATA 

5 PATH=$ORACLE_HOME/bin:/bin:/usr/bin:/etc; export PATH 

LD__LIBRARY_PATH=$ORACLE_HOME/lib; export LD_LIBRARY_PATH 



echo 


"" » $LOG 2>&1 






echo 


"" » $LOG 2>&1 






echo 


"TOP , 




STOP » SLOG 2>&1 


echo 


"FILE NAME , 


. n 


$FILE NAME » $LOG 


2>&1 








echo 


"ORACLE HOME 


. n 


$ORACLE_HOME » $L0G 


2>&1 








echo 


"ORACLE SID 


ii 


SORACLE SID » SLOG 


2>&1 








echo 




. n 


$USERID » $LOG 2>&1 


echo 




. ii 


$PASS » $LOG 2>&1 


echo 




. n 


$FAM_NAME » $LOG 2>&1 


echo 


"UI Flag 


ii 


$UI_FLAG » $LOG 2>&1 


echo 




. ii 


$STAUS_ENUM » $L0G 


2>&1 








echo 


"" » $LOG 2>&1 






echo 


"" » $LOG 2>&1 






sqlldr \ 








userid=$USERID/$PASS@$ORACLE 


SID 


\ 




data=$TOP/data/$FILE_NAME \ 







control=$TOP/ctl/ADD_TEMPLATE_HERE . ctl \ 
30 log=$SQL_LOG \ 

ba d= $ BAD_DATA \ 
errors=100000 \ 
bindsize=50000 \ 
direct=y » $LOG 2>&1 

35 

echo "" » $LOG 2>&1 
cat $SQL_L0G » $L0G 
rm -f $SQL_L0G 
echo "" » $LOG 2>&1 

40 

$ORACLE_HOME/bin/sqlplus -s $USERID/$PASS@$ORACLE_SID 
«EOF_RUN_TAG » $LOG 2>&1 
set pages 9999 
SET SCAN OFF 
45 set serveroutput on size 1000000 
set timing on 

prompt Executing map_ADD_TEMPLATE_HERE 
exec map_ADD__TEMPLATE_HERE ($UI_FLAG, $STATUS_ENUM) ; 
prompt commiting. 
50 commit ; 

prompt You are done. 
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exit 

EOF_RUN_TAG 
exit 0 

5 

In one embodiment, a loadsetupJND.sh file for vertical IND referenced by auto.ksh 
includes text such as the following excerpt: 

auto.ksh pvball 1085 1057 ind a pickone 
10 auto.ksh pvbfly 1273 1246 ind a pickone 

auto.ksh pvcheck 1274 1247 ind a pickone 

auto.ksh pvdiaph 1275 1248 ind a pickone 

auto.ksh pvgate 1276 1249 ind a pickone 

auto.ksh pvglobe 1277 1250 ind a pickone 
15 auto.ksh pvneedle 1278 1251 ind a pickone 

auto.ksh pvother 1279 1252 ind a pickone 



20 



In one embodiment, a map_template.sql file referenced by auto.ksh includes: 



— ************************************************************* 



— Name : ADD_TEMPLATE_HERE . sql 

25 — Usage : This script is executed by 

load_ADD_TEMPLATE_HERE.sh script. 

— Description: The following script would move data from the 
ADD_TEMPLATE_HERE temp 

table to the several tables on the pirns 

30 database. 

— ****************************************** ****************** f 

CREATE OR REPLACE PROCEDURE map_ADD_TEM PLAT E_HE RE (p_ui_flag 
integer default 0 f p_status_enum integer default 0) AS 

35 l_record ADD JTEMPLATE_HERE%ROWTYPE ; 
lv_err_text varchar2 ( 81) ; 

lv_err__num number; 
lv user varchar2 (30) ; 



= ADD_ATT_VAL_HERE; 
= ADD_NODE_VAL_HERE; 
= 0; 



lv_prod_att_def _id number ( 5 ) 
40 lv_defalut_node_id number (5) 

lv_jproduct_id number 

lv_sku_id number := 0; 

lv_flag number := 0; 

lv_count number := 0; 

45 lv_yersion number := 1; 

lv_text_id text_data . text_id%TYPE := 0; 

lv_supplier_id number := 0; 

lv_related_product RELATED_PRODUCT . RELATED_PRODUCT%TYPE; 
p_errnum number; 
50 p__errmsg varchar2 (81) ; 
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lv_check number; 
lv_buffer varchar2 (4000) := null; 

lv_jprod_desc_direction varchar2(3) := null; 
lv_clob__file_jname varchar(250) := null; 
lv_blob_file_name varchar(250) := null; 
p_text_data_version text_data . text_data_version%TYPE 
p blob data version text data. text data version%TYPE 



1 
1 



lv_file_loc__l 
lv_success 

10 lv_desc_dir_alias 
lv_blob_dir_alias 
lv_f ile_j?ath 
lv__f ile__tmp 
lv_session_id 

15 lv_sqlcode 

lv__orig_mfg_count 
lv short name 



number; 
varchar2 (3) 
varchar (30) 
varchar (30) 
varchar (250) 
varchar (250) 
number := 0; 
number := 0; 
number := 0; 
vendor . vendor short 



= 1 yes 1 ; 
= null; 
= null; 
= null; 
= null; 



name%TYPE := null; 



CURSOR c_get_all IS 
20 SELECT * 

FROM ADD TEMPLATE HERE; 
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cursor get_orig_mf g_entry is select distinct ORIG_MFG_ID, 

supplier_id 

from ADD_TEMPLATEJHERE 

where STATE ENUM = 4 or STATE ENUM is null ; 



BEGIN 

30 dbms_output . put_line (' Moving data from the ADD_TEMPLATE_HERE 
table to new schema.'); 

SELECT user 
INTO lv_user 
35 FROM dual; 



select userenv( 'SESSIONID' ) into lv_session_id FROM DUAL; 
OPEN c_get_all; 

40 

LOOP 

FETCH c_g<5t_all INTO l_record; 
EXIT WHEN c_get_all%NOTFOUND; 

45 lv_text_id := null; 

lv_product_id := 0; 
lv_sku_id : = 0; 

lv_clob_file_name := null; 
lv_jDlob_file_name := null; 

50 

begin 
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IF (l_record.SUPPLIER_ID is not null ) then 

lv_check : = tojnumber ( l_record . SUPPLIER_ID) ; 

ELSE 

dbms_output . put_line ( ' ERROR s ku_id= 1 I I 1 v_s ku_id 
5 || 1 was not inserted; supplier ID is NULL. 1 ); 

lv_success := 'no'; 
GOTO end_of_loop; 
END IF; 
EXCEPTION 
10 WHEN OTHERS THEN 

lv_err_text := SUBSTR ( SQLERRM ,1,80); 

dbms_output . put_line ( 1 ERROR sku_id= 1 | | lv_sku_id 

I | 1 was not inserted; supplier ID is not a number . ' ) ; 
lv_success 'no'; 
15 GOTO end_of_loop; 

END; 

lv_file_loc_l := 0 ; 

20 IF (l_record.PROD_DESC_DATA IS NOT NULL) then 

lv_prod_desc_direction : = 
substr ( l__r ecord . PROD_DESC_DATA, 1,1); 

IF lv_prod_desc_direction = ' /' THEN 

lv_file_loc_l :== INSTR (l_record. PROD_DESC_DATA, '/', 

25 -1, 1) ; 

lv_file_j)ath := 1 1 ' 1 | | 
substr (l_record. PROD_DESC_DATA, 1, lv_f ile_loc_l - 1) ; 
lv_filejpath lv_file_path | | 

30 lv_clob_file^jiame : = 

substr (l_record. PROD_DESC_DATA, lv_f ile_loc_l+l) ; 

— dbms_output.put_line ('Directory full path : ' || 
lv_f ile_path) ; 

— dbms_output.put_line ('File name : ' || 

35 lv_clob_f ile_name) ; 

lv_desc_dir_alias := 1 ADD_TEMPLATE_HERE ' | | 
lv_session_id I I 'clob_dir'; 

— dbms_output.put_line ('Directory alias is ; ' || 
40 lv_desc_dir__alias ) ; 

BEGIN 

EXECUTE IMMEDIATE ' drop directory ' | | 
lv__desc_dir__alias; 
45 ^ EXCEPTION 

WHEN OTHERS THEN 
null; 

END; 

50 SAVEPOINT my_save_p; 
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EXECUTE IMMEDIATE 'create directory ' | | 
lv_desc_dir_alias | I 1 as 1 | | lv_f ilejpath; 
text_data_clob { 
1 v_c 1 ob_f i 1 e_n ame , 
5 p_text_data__version, 

1 ADD_TEMPLATE_HERE 1 , 
'f, 

lv_session_id, 
lv_text__id, 
10 p_errnum, 

p_errmsg) ; 

IF ( p_errnum != 0 ) THEN 

dbms_output . put_line ( 1 ERROR Sku_id= 1 | I 

15 lv_sku_id 

| | 1 was not inserted. Error loading text 

file=' 

|| l_record.PROD_DESCJDATA ); 
dbms_output . put_ line ( "Error num: 1 || 
20 pjrrnum I | p_errmsg ) ; 

rollback to my_save_j>; 
lv_success : = 'no'; 
GOTO end_of_loop; 
25 END IF; 

ELSE 

SAVEPOINT my_save_p; 

text__data_clob ( 
l_record . PROD_DESC_DATA, 
30 p_t e x t_da t a_ve r s ion, 

' ADD_TEMPLATE__HERE ' , 
'f, 

lv_session_id, 
lv_text_id, 
35 p_errnum, 

p_errmsg) ; 

IF ( p_errnum ! = 0 ) THEN 

dbms_output . put_line ( 1 ERROR inserting prod_desc : 
40 Sku=' || lv_sku_id); 

dbms__output.put_line( 'Error num: 1 || 
p_errnum| |p_errmsg) ; 

rollback to my_save_jp; 
45 lv_success := 'no 1 ; 

GOTO end_of_loop; 
END IF; 
END IF; 
END IF; 



50 



IF ( l_record.related_product IS NULL ) THEN 
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lv_related_product : = 1 Unspecified 1 ; 
else 

lv_relatedj?roduct := l_record. relatedjproduct; 
end if; 

SELECT product_id.NextVal 
INTO lv_product_id 
FROM dual; 

select sku_id . NextVal 
into lv_sku_id 
from dual; 

BEGIN 

INSERT INTO product ( 

PRODUCT_ID, 

PROD_ATT_DEF_ID, 

DEFAULT_NODE_ID, 

CREATE__DATE , 

CREATED_BY, 

ORIG_MFG_ID, 

PROD_NAME, 

PROD_DESC_ID, 

SUPPLIER_ID, 

REFERENCE/ 

SYNONYMS, 

PROD_GA500X1, 

APPLICATION, 

PROD_GA500X2, 

PROD_GA500X3, 

SHIPPING JTYPEJENUM, 

ADD_INFO, 

PR0D_GA1X1, 

PR0D_GA1X2, 

PR0D_GA1X3, 

PROD_GA500X4, 

PROD_GA250X1, 

PRODJ3A1X4, 

PROD_GA250X2, 

PR0D_GA1X5, 

PR0D_GA1X6, 

REVIEW_ENUM, 

AGENCY_ENUM, 

REGULATORY_SCHEDULE_ENUM, 
REGULATORY_ACT ION_ENUM , 
Modif ied_date, 
Modif ied_by, 
SUPPLIER JPRODUCTJSfAME, 
unspsc_code, 
status_enum 

ADD_PROD_GA HERE) 
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VALUES ( 

lv_product_id, 

ljrecord. PROD_ATT_DEF_ID, 

ljrecord. DEFAULT_NODE_ID, 

sysdate, 

lv_user, 

ljrecord . ORIG_MFG_ID, 

ljrecord. PRODJNAME, 

lv__text_id, 

l_record . SUPPLIER_ID, 

ljrecord . REFERENCE, 

l_record . SYNONYMS , 

ljrecord. PROD_GA500X1, 

l_record . APPLICATION, 

l_record. PROD_GA500X2, 

ljrecord. PRODJ3A5 00X3, 

ljrecord .SHI PPINGJT YPE , 

l_record . ADD_INFO, 

l_record . PR0D_GA1X1 , 

l_record. PR0D_GA1X2, 

l_record. PROD_GAlX3, 

l_record . PROD_GA500X4 , 

l_record. PROD_GA250X1, 

l_record . PR0D_GA1X4 , 

ljrecord. PROD_GA2 5 0X2, 

ljrecord . PROD_GAlX5 , 

ljrecord. PRO D_GA1X6, 

ljrecord . RE VIEW_ENUM , 

l_record . AGENCY_ENUM, 

ljrecord . RE GULATOR YJS CHE DULE__EN UM , 

ljrecord. REGULATOR Y_ACTION_ENUM, 

sysdate, 
'PIMSJLOAD' , 

l_record . SUPPLIER_PRODUCT_NAME , 
ljrecord . unspsc_code , 

p_status_enum 
ADD_PROD_GA_VAL_HERE 
) ; 

EXCEPTION 

WHEN OTHERS THEN 

lv_err_num : = SQLCODE; 

lv_err_text := SUBSTR ( SQLERRM ,1,80) ; 

dbms_output . put_line ( 1 ERROR Sku_id= 1 || lv_sku_id || 1 was 
not inserted. Error inserting into the Product table.'); 

dbms_output .put_line ( 1 Error # : ' || 
lv_err_num| | lv_err_text) ; 

rollback to my_savejp; 
lv_success := 'no'; 
GOTO end_of_loop; 
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END; 
BEGIN 

INSERT INTO sku ( 

SKUJCD, 

SKU_VERSION, 

PRODUCT_ID, 

CREATEJDATE, 

CREATED_BY, 

UNIT, 

QTY, 

UNIT_MULTIPLIER, 

WEIGHT, 

SHIP_WT, 

CMDX_SKU, 

SUPPLIER_CAT_NUM, 

BARCODE, 

STATE_ENUM, 

ORIG_MFG_CAT_NUM, 

Modif ied_date , 

modif ied_by, 

status_enum, 

splr_cat_number_dif f erentiator, 
normalized_unit_multiplier, 
normal i zed_qty , 
normalized_unit) 

VALUES ( 
lv_sku_id, 
lv_version, 
lvj?roduct_id, 
sysdate, 
lv_user, 

l_record . unit , v. 
l_record.qty, 

nvl (l_record.unit_multiplier, 1) , 
l_record . weight , 
l_record. ship_wt, 
lv_sku_id, 

l_record. supplier_cat_num, 

l_record. barcode, 

l_record. STATE_ENUM, 

l_record. orig_mf g_cat_num, 

sysdate, 

f PIMS_LOAD», 

p_status_enum, 

null, 

l_record.nomalized_unit_multiplier, 

l_record.normalized_qty, 

l_record. normalized unit); 
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EXCEPTION 

WHEN OTHERS THEN 

lv_errjnum := SQLCODE; 

lv_err_text := SUBSTR (SQLERRM, 1, 80) ; 

5 

begin 

select vendor_short_name 
into lv_short_name from vendor 
where vendor_id = l_record. SUPPLIER_ID 
10 and vendor_short_name is not null; 

EXCEPTION 

WHEN OTHERS THEN 
null; 

END; 

15 

dbms_output . put_line ( 1 ERROR inserting into the Sku 
table; Sku = 1 It lv_sku_id) ; 

dbms_output .put_line ( 'Error # : 1 II 

lv_err_num | | lv_err_text) ; 
20 — dbms_output .put_line( ' lv_sku_id : 1 II 

lv_sku_id) ; 

— dbms_output .putJLine ( 1 lv_jproduct_id : 1 II 
1 v_pr oduc t_id ) 



dbms_output . put_line ( 1 CMDX Sku 
25 dbms_output . put_line ( 1 Vendor 

1 v__shor t_name ) ; 

dbms_output . put__line ( 1 supp cat num 
l_record . supplier_cat_num) ; 

dbms_output . put_line ( 1 QTY 
30 l__record . qty ) ; 

dbms_output . put_line ( ■ Unit 
l_record.unit) ; 

dbms_output . put_line ( 1 Unit Mul 
NVL(l_record.unit_multiplier, 1) ) ; 
35 dbms_output . put — line ( ' . 1 ) ; 

rollback to my_savejp; 
lv_success : = 1 no 1 ; 
GOTO end_of_loop; 
40 END; 

BEGIN 

INSERT INTO price ( 

PRICE_ID, 
45 BUYER_ID, 

BUYER_SEG_ID, 

SUPPLIER_ID, 

SKUJCD, 

MINJJTY, 
50 PRICE_VERSION, 

CREATED_BY, 

71 



lv sku id) ; 



WO 02/073493 



PCT/US01/25468 



CREATE JDATE, 
PRICE, 

MODIFIED_BY, 
MODIFIEDJDATE, 
STATE_ENUM, 
STATUS_ENUM, 
USE_LIST_DSCNT, 
FROMJEFFECTIVE_DATE , 
TO_EFFECTIVE_DATE , 
LISTJ)SCNT_PCT) 
values ( 

PRICE_ID.NEXTVAL, 

0, 
0, 

l_record. SUPPLIER_ID, 

lv_sku_id, 

0, 

1000000, 
lv_user, 
sysdate, 

l_record . list jpr ice , 
■PIMS_LOAD f , 
sysdate, 

l_record. state_enum, 

p_status_enum, 

null, 

to^dateCOl-JAN-OOOl', 1 DD-MON-YYYY 1 ) r 
to_date( , 31-DEC-9999' , 1 DD-MON-YYYY 1 ) , 
null) ; 
EXCEPTION 

WHEN OTHERS THEN 

lv_err_num := SQLCODE; 

lv_err_text := SUBSTR (SQLERRM, 1,80) ; 

dbms_output . put_line ( 1 ERROR Sku_id= 1 | I lv_sku_id 

| | 1 was not inserted- Error inserting unaffiliated 
price sheet. 1 ) ; 

dbms_output .put_line ( 1 Error # : 1 | | lv_err_num) ; 

rollback to my_save_p; 
lv_success : = 'no'; 
GOTO end__of_loop; 
END; 

BEGIN 

INSERT INTO related_product ( 

PRODUCTJED, 

SORTJDRDER, 

REFERENCE_PROD_ID, 

REFERENCE_TYPE_ENUM, 

RELATIONJTYPE_ENUM, 

RELATED_PRODUCT, 



72 



WO 02/073493 



PCT/US01/25468 



EXTERNAL_RE FERENCE , 

STATUS_ENUM 

) 

VALUES ( 
5 lvjproduct_id, 
1, 

null, 
null, 
null, 

10 lv_r elated ^product , 

null, 

p_s t a t u s_e num 
) ; 

15 EXCEPTION 

WHEN OTHERS THEN 

lv_err_num : = SQLCODE; 

lv_err_text := SUBSTR (SQLERRM, 1, 80) ; 

dbms_output . put_line ( 1 ERROR Sku_id= 1 | | lv_sku_id 
20 ||' was not inserted. Error inserting into Related 

Product ' ) ; 

dbms_output . put_line ( f Error # : ' | | lv_err_num) ; 

rollback to my_save_p; 
25 lv_success := 'no'; 

GOTO end_of_loop; 
END; 

/* 

30 IF (l_record.blob_jfile_name IS NOT NULL) then 

mime_data_blob ( 
1 v_blob_f ile_name , 
p_blob__data_version, 
35 1 ADDJTEMPLATEJKERE 1 , 

lv_session_id, 
lv_sku_id, 
p_errnum, 
p_errmsg) ; 

40 

IF ( p__errnum != 0 ) THEN 

dbms_output.put_line( 'ERROR Sku_id=' || lv_sku_id 
| | ' was not inserted. Error loading binary file 
II l_record.blob_file_name) ; 
45 dbms_output.put_line( 'Error num: 1 | \ p_errnum) ; 

rollback to my_savejp; 
lv_success : = ' no ' ; 
GOTO end_of_loop; 
50 END IF; 
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END IF; 

*/ 

< <end_o fJL oop» 

5 

IF lv_success = 'yes' THEN 
lv_count := lv_count + 1; 
END IF; 

10 lv^success := 'yes'; 

lv_flag := mod(lv_count, 1000); 

IF ( (lv_flag = 0) and (lv_courit > 0) ) THEN 

dbms_output .put_line ( 'Commiting at 1 | | lv_count I | 1 . 1 ) ; 
15 commit; 
END IF; 

END LOOP; 

20 CLOSE c_get_all; 

FOR get_one_rec in get_origjnfg_entry LOOP 

lv_orig_mfg__count := 0; 
25 — IF (get_6ne__rec.ORIG_MFG_ID is NULL ) THEN 
begin 

select count (SUPPLIER_ID) 

into lv__orig_mf g_count 
from ORIG_MFG 

where SUPPLIER_ID = get_one_rec. SUPPLIER_ID 
and ORIG_MFG_ID = get_one_rec. SUPPLIERJED; 



30 



IF (lv_orig_mfg_count = 0) THEN 

insert into ORIG_MFG ( SUPPLIER_ID, ORIG MFG ID, 
35 UI_FLAG) " 

values (get_one_rec . SUPPLIER_ID, - 
get_one_rec.SUPPLIER_ID, p_ui_f lag) ; 
END IF; 
exception 

40 WHEN OTHERS THEN 

lv_sqlcode := sqlcode; 

if ( lv_sqlcode = -1 ) then 

null; — It is OK, record may already 

exist. 

45 else * 

dbms_output .put_line ( 'Error inserting into 
Origjyffg table; please contact DBA group. 1 ); 
end if; 

end; 
50 — ELSE 

IF (get_one_rec.ORIGJMFG_ID is NOT NULL ) THEN 
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begin 

select count (SUPPLIERJED) 

into lv_orig_mfg_count 
from ORIGJ4FG 

5 where SUPPLIER_ID = get_one_rec. SUPPLIER_ID 

and ORIG_MFG_ID = get_one_rec.ORIG_MFG_ID; 

IF (lv_orig_mfg_count = 0) THEN 

insert into ORIG_MFG ( SUPPLIERJCD, OR I G_MFG_I D , 

10 UI_FLAG) 

values (get_one_rec . SUPPLIER_ID, 
get_one_rec.ORIG_MFG_ID, p_ui_flag) ; 
END IF; 
exception 
15 WHEN OTHERS THEN 

lv__sqlcode := sqlcode; 

if ( lv_sqlcode = -1 ) then 

null; — It is OK, record may already 

exist. 

20 else 

dbms_output . put_line ( 1 Error inserting into 
Orig_Mfg table; please contact DBA group.'); 
end if ; 

end; 

25 END IF; 

END LOOP; 

dbms_output .put_line (lv_count || 1 Products have been 
30 inserted. 1 ) ; 

commit; 

— Some clean up for all dir aliases; 
35 BEGIN 

EXECUTE IMMEDIATE 'drop directory 1 || 
1 v_de s c__di r_a lias; 
EXCEPTION 

WHEN OTHERS THEN 
40 null; 
END; 

BEGIN 

EXECUTE IMMEDIATE 'drop directory 1 || 
45 1 v_b 1 ob_di r_a lias; 
EXCEPTION 

WHEN OTHERS THEN 
null; 

END; 

50 

EXCEPTION 
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WHEN OTHERS THEN 

lv_errj:ext := SCJBSTR(SQLERRM, 1, 80) ; 

dbms_output . put_line ( 1 Error map_ADD_TEMPLATE_HERE Main : 
I | lv err text) ; 



END map_ADD_TEMPLATE_HERE; 
/ 

show errors; 
exit; 



In one embodiment, a templatextl file referenced by auto.ksh includes: 



load data 
replace 

15 into table ADD_TEMPLATE_HERE 
FIELDS TERMINATED BY "|" 
TRAILING NULLCOLS 
( 



5 



rollback; 



10 



50 



45 



40 



35 



25 



30 



20 



cmdx_sku_id , 
PROD_ATT_DEF_ID, 
DEFAULT_NODE_I D , 
Or i g_Mf g_Ca t_N um 
Orig_Mfg_Id , 
Prod_Name , 
prod_desc_data , 
Supplier_Id , 
Weight , 
Barcode , 
List_Price , 
Supplier_Cat_Num 
Qty , 
Unit , 

UnitJMultiplier , 
STATEJENUM, 
reference , 
relatedjproduct , 
Synonyms , 
prod_GA500Xl , 
application , 
Prod_GA500X2 , 
Prod_GA500X3 , 
Ship_Wt , 
Shipping_Type , 
add_info , 
Prod_GAlXl , 
Prod_GAlX2 , 
Prod_GAlX3 , 
Prod_GA500X4 , 
Prod_GA250Xl , 
Prod_GAlX4 , 
Prod GA250X2 , 
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Prod_GAlX5 , 
Prod_GAlX6 , 
REVI EW_EN0M , 
AGENCY_ENUM , 
REGULATORY_SCHEDULE_ENUM, 
REGULATORY_ACTION_ENUM, 
SUPPLIER_PRODUCT_NAME , 
UNSPSC_CQDE, 

NORMALIZED_UNIT_MULTIPLIER, 

NORMALIZED_QTY, 

NORMALIZEDJJNIT 

ADD_GA_HERE 

) 



In one embodiment, a template.sql file referenced by auto.ksh includes: 



drop table ADD_TEMPLATE_HERE cascade constraints; 



TEMPLATE 
Id 



CREATE TABLE ADD 
CMDX_Sku_ 
prod_Att_Def_id 
default_Node_ID 
Or i g_Mf g_Cat_Num 
Orig_Mfg_Id 
Prod_Name 
prod_desc_data 
Supplier_Id 
Weight 
Barcode 
List_Price 
Supplier_Cat_Num 
Qty 
Unit 

Unit_Multiplier 
state_enum 
reference 
related_product 
Synonyms 
prod_GA500Xl 
application 
Prod_GA500X2 
Prod_GA500X3 
Ship_Wt 
Shipping_Type 
add_info 
Prod_GAlXl 
Prod_GAlX2 
Prod_GAlX3 
Prod_GA500X4 
Prod GA250X1 



_HERE ( 

varchar2 (120) NOT NULL, 
number (12) NOT NULL, 
number (12) NOT NULL, 
VARCHAR2(64) NULL, 
NUMBER (12) NULL, 
VARCHAR2 (500) NULL, 
VARCHAR2 (4000) NULL, 
varchar2 (120) NULL; 
NUMBER (15, 5) NULL, 
NUMBER (20) NULL,- 
NUMBER (10, 2) NULL, 
VARCHAR2(64) NULL, 
NUMBER NULL, 
VARCHAR2(20) NULL, 
NUMBER (8) NULL, 
NUMBER (5) NULL, 

VARCHAR2(4000) NULL, 
VARCHAR2(500) NULL, 
VARCHAR2(2000) NULL, 
VARCHAR2(500) NULL, 
VARCHAR2(4000) NULL, 
VARCHAR2 (500) NULL, 
VARCHAR2(500) NULL, 
NUMBER (15, 5) NULL, 
NUMBER (12) NULL, 
VARCHAR2(4000) NULL, 
CHAR(l) NULL, 
CHAR(l) NULL, 
CHAR(l) NULL, 
VARCHAR2(500) NULL, 
VARCHAR2(250) NULL, 
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10 



5 



Prod_GAlX4 CHAR(l) NULL, 

Prod_GA250X2 VARCHAR2 (250) NULL, 

Prod_GAlX5 CHAR(l) NULL, 

Prod_GAlX6 CHAR(l) NULL, 

REVIEW_ENUM NUMBER (5) NULL, 

AGENCY JENUM NUMBER (5) NULL, 

REGULATORY_SCHEDULE_ENUM NUMBER (5) NULL, 
REGULATOR Y_ACTION_ENUM NUMBER (5) NULL, 

supplier^ product_name VARCHAR2 (500) , 

unspsc_code VARCHAR2 (50) , 

normalized_unitjnultiplier NUMBER, . 
n o rma 1 i z ed_qt y NUMBER , 

normalized_unit NUMBER 
ADD GA HERE 



15 



); 

quit 



In one embodiment, the load setup.out script invokes the auto.ksh script, which uses 



various files together with the ontology values passed as parameters by load_setup.out script in 
20 order to produce engineering configuration files. 



In summary, the present invention provides tools and techniques for automatically 
generating marketplace web site configuration files and other configuration materials (e.g., 

25 supplier documentation) from an express structural ontology specification. The structural 
ontology specification 406 can expressly specify a data type, and perhaps also a data size, for 
at least one attribute using, e.g., a "Data type" column in a spreadsheet 804. The specification 
406 can expressly specify allowed data values for at least one attribute using, e.g., an "Allowed 
values (for ENUMS)" column in such a spreadsheet 804. The specification 406 can expressly 

30 specify a search type for at least one attribute using, e.g., a "Search method" column in such a 
spreadsheet 804. The specification 406 can expressly specify that at least one attribute is 
mandatory or that it is optional using, e.g., Y or N values respectively in a "Required? (Y or 
N)" column in such a spreadsheet 804. The specification 406 can expressly specify a mapping 
between an attribute and a product relational database field using, e.g., PIMS Mapping and 

35 Att_Def_Id columns in a such spreadsheet 804. It may also specify other ontological 
characteristics of the marketplace, but the focus here is on structural ontology rather than 
transactional ontology. 

The invention does not solve all configuration problems of market site providers. Even 
when scripts are used to generate 506 configuration files from an express structural ontology 

40 specification 406, bugs that need fixing may occur. For example, if an ontology .properties file 
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is changed but corresponding radio.properties and enum.properties files are not updated as 
well, then problems may occur. In one such case, enum file order sequencing incorrectly 
counted text-boxes as drop-downs when a text-box preceded a drop-down, which threw off the 
enum display listings. In addition, problems may occur as a result of human errors when 
creating or updating the express structural ontology specification 406 itself. Nonetheless, the 
invention facilitates marketplace configuration by providing greater consistency and ease of 
revision in some cases. In addition to their consistency with an authoritative ontology 
specification 406 and their relative ease of generation once the invention is implemented, 
automatically generated configuration files 808 can provide other advantages over manually 
produced configuration files. For instance, automatically generated prod_att_def_id files can 
be easily produced in sorted form. 

In general, file excerpts shown above are not exclusive, in that embodiments of the 
invention may have files containing additional text; words such as "contains" and "includes" 
should be understand accordingly to mean "comprises". There may also be some duplication, 
such that information appears in more than one of the applications (namely, the three 
incorporated provisional applications or the present application) or more than once in a 
particular application. Extraneous information, blank lines, and other white space have 
sometimes been removed, fonts have been changed, and other formatting steps were taken. 

More generally, it should also be noted that the applications may contain more detail 
than is required by law in a patent U.S. patent case law indicates, for example, that computer 
source code is not necessarily required in an application, but several script source codes are 
included in the applications. These implementation details are provided in order to err - if 
errors are being made - by including too much information rather than including too little. 
Applicants should not be penalized for being so forthcoming. In particular, the inclusion of 
details in an application should not be viewed as an assumption or admission that those details, 
or similar details, or a similar level of detail, are actually required to support the claims 
ultimately granted. Nor should the inclusion of particular implementation details be 
misinterpreted by treating as inventors people who simply implemented inventive ideas 
conceived by others. 

Articles of manufacture within the scope of the present invention include a computer- 
readable storage medium in combination with the specific physical configuration of a substrate 
of the computer-readable storage medium. The substrate configuration represents data and 
instructions which cause the computers to operate in a specific and predefined maimer as 
described herein. Suitable storage devices include hard disks, CD-ROMs, and other media 
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readable by computers. Each such medium tangibly embodies a program that is executable by 
a computer system to perform steps substantially as described herein to use an express 
structural ontology specification of a marketplace as a basis for automatically generating 
configuration materials for the marketplace. 
5 Although particular methods embodying the present invention are expressly illustrated 

and described herein, it will be appreciated that system and configured storage medium 
embodiments may also be formed according to the methods of the present invention. Unless 
otherwise expressly indicated, the descriptions herein of methods of the present invention 
therefore extend to corresponding systems and configured storage media, and the descriptions 

10 of systems and configured storage media of the present invention extend likewise to 

corresponding methods. An "embodiment" of the invention may be, without limitation, a 
system, an article of manufacture, a method, and/or a computer memory, CD, disk, or other 
digital or analog medium that is configured according to the invention. The method steps may 
be performed in various orders, except in those cases in which the results of one step are 

15 required as input to another step. Likewise, steps may be omitted unless called for in issued 
claims, regardless of whether, they are expressly described as optional in this Detailed 
Description. Steps may also be repeated, combined, or named differently. 

All claims as filed are part of the specification and thus help describe the invention, and 
claim language may be repeated outside the claims as needed. As used herein, terms such as 

20 "a" and "the" and designations such as "file", "attribute", and "script" are inclusive of one or 
more of the indicated element. In particular, in the claims a reference to an element normally 
means at least one such element is required. 

The invention may be embodied in other specific forms without departing from its 
essential characteristics. The described embodiments are to be considered in all respects only 

25 as illustrative and not restrictive. Headings are for convenience only. The scope of the 
invention is, therefore, indicated by the appended claims rather than by the foregoing 
description. All changes which come within the meaning and range of equivalency of the 
claims are to be embraced within their scope. 

What is claimed and desired to be secured by patent is: 
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CLAIMS 

1 . A method for facilitating electronic commerce, comprising the steps of: 

(a) obtaining an express structural ontology specification for a particular 
electronic commerce marketplace, the structural ontology specification: 

(i) being organized in a predefined format so that it can be parsed by a 
computer, 

(ii) being an express and hence human-readable specification rather than being 
merely implicit in computer program code, and 

(iii) expressly specifying at least product categories, product generic attributes, 
and product category attributes; 

(b) automatically parsing the structural ontology specification using a 
computerized tool which also parses other structural ontology specifications written in 
the predefined format; 

(c) extracting ontology information from the structural ontology specification 
using a computerized tool which also extracts ontology information from other 
structural ontology specifications; and 

(d) using ontology information extracted from the structural ontology 
specification to automatically generate for the electronic commerce marketplace 
configuration materials, at least some of which configuration materials are not product 
catalog files. 

2. The method of claim 1 , wherein the method uses ontology information extracted 
from the structural ontology specification to automatically generate configuration files that 
include at least three of: 

a user interface configuration file, 
a search interface configuration file, 
a file containing a user interface quality assurance checklist, 
a file containing a search interface quality assurance checklist, 
a file containing a framework of a script for extracting product data from a text 
file and loading the product data into a product relational database, 
a file containing a product data quality assurance script, and 
product catalog files. 

3 . The method of claim 1 , wherein the method uses ontology information extracted 
from the structural ontology specification to automatically generate configuration files that 
include at least four of : . 
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a user interface configuration file, 
a search interface configuration file, 
a file containing a user interface quality assurance checklist, 
a file containing a search interface quality assurance checklist, 
a file containing a framework of a script for extracting product data from a text 
file and loading the product data into a product relational database, 
a file containing a product data quality assurance script, and 
product catalog files. 

4. The method of claim 1, wherein the method uses ontology information extracted 
from the structural ontology specification to automatically generate configuration files that 
include at least five of: 

a user interface configuration file, 
a search interface configuration file, 
a file containing a user interface quality assurance checklist, 
a file containing a search interface quality assurance checklist, 
a file containing a framework of a script for extracting product data from a text 
file and loading the product data into a product relational database, 
a file containing a product data quality assurance script, and 
product catalog files. 

5. The method of claim 1, wherein the method uses ontology information extracted 
from the structural ontology specification to automatically generate configuration files that 
include at least six of: 

a user interface configuration file, 
a search interface configuration file, 
a file containing a user interface quality assurance checklist, 
a file containing a search interface quality assurance checklist, 
a file containing a framework of a script for extracting product data from a text 
file and loading the product data into a product relational database, 
a file containing a product data quality assurance script, and 
product catalog files. 

6. The method of claim 1, wherein the structural ontology specification expressly 
specifies a data type for at least one attribute. 

7. The method of claim 1 , wherein the structural ontology specification expressly 
specifies a data size for at least one attribute. 

82 



WO 02/073493 PCT/US01/25468 

8. The method of claim 1, wherein the structural ontology specification expressly 
specifies allowed data values for at least one attribute. 

9. The method of claim 1, wherein the structural ontology specification expressly 
specifies a search type for at least one attribute. 

5 10. The method of claim 1 , wherein the structural ontology specification expressly 

specifies that at least one attribute is mandatory. 

1 1 . The method of claim 1 , wherein the structural ontology specification expressly 
specifies that at least one attribute is optional. 

12. The method of claim 1 , wherein the structural ontology specification expressly 
10 specifies a mapping between an attribute and a product relational database field. 

13. The method of claim 1 , wherein the method uses ontology information extracted 
from the structural ontology specification to automatically generate at least one user interface 
configuration file. 

14. The method of claim 13, wherein the method automatically generates a user 
1 5 interface search configuration file. 

15. The method of claim 13, wherein the method automatically generates a user 
interface product display configuration file. 

1 6. The method of claim 1 , wherein the method uses ontology information extracted 
from the structural ontology specification to automatically generate at least one search 

20 interface configuration file. 

17. The method of claim 16, wherein the method automatically generates a search 
interface initial database request configuration file. 

18. The method of claim 1 6, wherein the method automatically generates a search 
interface product detail request interface configuration file. 

25 19. The method of claim 1 , wherein the method uses ontology information extracted 

from the structural ontology specification to automatically generate at least one catalog 
configuration file. 

20. The method of claim 1 9, wherein the method automatically generates a catalog 
mapping sheet configuration file. 
30 21. The method of claim 1 9, wherein the method automatically generates a catalog 

enumeration load sheet configuration file. 

22. The method of claim 1 , wherein the method uses ontology information extracted 
from the structural ontology specification to automatically generate at least one file containing 
a user interface quality assurance checklist 
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23 . The method of claim 1 , wherein the method uses ontology information extracted 
from the structural ontology specification to automatically generate at least one file containing 
a search interface quality assurance checklist 

24. The method of claim 1 , wherein the method uses ontology information extracted 
from the structural ontology specification to automatically generate at least one file containing 
a framework of a script for extracting product data from a text file. 

25. The method of claim 1, wherein the method uses ontology information extracted 
from the structural ontology specification to automatically generate at least one file containing 
a framework of a script for loading product data into a product relational database. 

26. The method of claim 1 , wherein the method uses ontology information extracted 
from the structural ontology specification to automatically generate at least one file containing 
a product data quality assurance script. 

27. The method of claim 1 , wherein the method uses ontology information extracted 
from the structural ontology specification to automatically generate at least one configuration 
file for a graphical product data entry tool which accepts product data entered manually by a 
user and places the product data in a product relational database. 

28. The method of claim 1 , wherein the method uses ontology information extracted 
from the structural ontology specification to automatically generate at least one file containing 
documentation which describes product data that is requested from a supplier regarding 
products to be offered in the electronic commerce marketplace. 

29. A computer system, comprising: 

(a) an express structural ontology specification for a particular electronic 
commerce marketplace, the structural ontology specification: 

(i) being organized in a predefined format so that it can be parsed by a computer 
in the system, 

(ii) being an express and hence human-readable specification rather than being 
merely implicit in computer program code, and 

(iii) expressly specifying at least product categories, product generic attributes, 
and product category attributes; 

and 

(b) a computerized file generation means for parsing the structural ontology 
specification, extracting ontology information from title structural ontology 
specification, and using the ontology information to automatically generate for the 
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electronic commerce marketplace configuration materials, at least some of which 
configuration materials are not product catalog files. 

30. The system of claim 29, wherein the file generation means automatically 
generates configuration files that include at least two of: 

a user interface configuration file, 

a search interface configuration file, 

a file containing a user interface quality assurance checklist, 

a file containing a search interface quality assurance checklist, 

a file containing a framework of a script for extracting product data from a text 

file, 

a file containing a framework of a script for loading the product data into a 

product relational database, 

a file containing a product data quality assurance script, 

a configuration file for a graphical product data entry tool, 

a file containing documentation which describes product data that is requested 

from a supplier, and 

a catalog configuration file. 

3 1 . The system of claim 29, wherein the file generation means automatically 
generates configuration files that include at least four of: 

a user interface configuration file, 

a search interface configuration file, 

a file containing a user interface quality assurance checklist, 

a file containing a search interface quality assurance checklist, 

a file containing a framework of a script for extracting product data from a text 

file, 

a file containing a framework of a script for loading the product data into a 

product relational database, 

a file containing a product data quality assurance script, 

a configuration file for a graphical product data entry tool, 

a file containing documentation which describes product data that is requested 

from a supplier, and 

a catalog configuration file. 

32. The system of claim 29, wherein the file generation means automatically 
generates configuration files that include at least six of: 
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a user interface configuration file, 
a search interface configuration file, 
a file containing a user interface quality assurance checklist, 
a file containing a search interface quality assurance checklist, 
a file containing a framework of a script for extracting product data from a text 

file, 

a file containing a framework of a script for loading the product data into a 

product relational database, 

a file containing a product data quality assurance script, 

a configuration file for a graphical product data entry tool, 

a file containing documentation which describes product data that is requested 

from a supplier, and 

a catalog configuration file. 

33. The system of claim 29, wherein the file generation means automatically 
generates configuration files that include at least eight of: 

a user interface configuration file, 

a search interface configuration file, 

a file containing a user interface quality assurance checklist, 

a file containing a search interface quality assurance checklist, 

a file containing a framework of a script for extracting product data from a text 

file, 

a file containing a framework of a script for loading the product data into a 

product relational database, 

a file containing a product data quality assurance script, 

a configuration file for a graphical product data entry tool, 

a file containing documentation which describes product data that is requested 

from a supplier, and 

a catalog configuration file. 

34. The system of claim 29, wherein the structural ontology specification expressly 
specifies at least one of: data type for at least one attribute, and a data size for at least one 
attribute. 

35. The system of claim 29, wherein the structural ontology specification expressly 
specifies allowed data values for at least one attribute. 
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36. The system of claim 29, wherein the structural ontology specification expressly 
specifies a search type for at least one attribute. 

37. The system of claim 29, wherein the structural ontology specification expressly 
specifies that at least one attribute is mandatory and/or specifies that at least one attribute is 

5 optional. 

38. The system of claim 29, wherein the structural ontology specification expressly 
specifies a mapping between an attribute and a product relational database field. 

39. The system of claim 29, wherein the file generation means comprises a script 

40. The system of claim 29, wherein the structural ontology specification comprises 
10 a spreadsheet file. 

41. A computer system, comprising: 
a processor; 

memory accessible to the processor configured by an express structural 
ontology specification for a particular electronic commerce marketplace; and 
15 software for the processor which uses ontology information read from the 

structural ontology specification to generate for the electronic commerce marketplace 
configuration materials, at least some of which configuration materials are not product 
catalog files. 

42. The system of claim 41 , in which the software comprises a script 

20 43. The system of claim 41 , in which the software comprises at least two scripts, 

and one script invokes the other script. 

44. The system of claim 4 1 , in which the software generates interface configuration 



files. 



25 files. 



45. The system of claim 41, in which the software generates catalog configuration 

46. The system of claim 41, in which the software generates quality assurance files. 

47. The system of claim 41, in which the software generates supplier documentation 



files. 



48. The system of claim 41, in which the software generates data extraction files. 
30 49. The system of claim 41, in which the software generates database load files. 

50. A computer-readable storage media configured to perform a method comprising 
the steps of parsing an express structural ontology specification, extracting ontology 
information from the structural ontology specification, and using the ontology information to 
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automatically generate for the electronic commerce marketplace configuration materials, at 
least some of which configuration materials are not product catalog files. 

5 1 . The configured medium of claim 50, wherein the method automatically 
generates a user interface search configuration file. 
5 52. The configured medium of claim 50, wherein the method automatically 

generates a user interface product display configuration file. 

53. The configured medium of claim 50, wherein the method automatically 
generates a search interface initial database request configuration file. 

54. The configured medium of claim 50, wherein the method automatically 
10 generates a search interface product detail request interface configuration file. 

55. The configured medium of claim 50, wherein the method automatically 
generates a catalog mapping sheet configuration file. 

56. The configured medium of claim 50, wherein the method automatically 
generates a catalog enumeration load sheet configuration file. 

15 57. The configured medium of claim 50, wherein the method uses ontology 

information extracted from the structural ontology specification to automatically generate at 
least one file containing a user interface quality assurance checklist. 

58. The configured medium of claim 50, wherein the method uses ontology 
information extracted from the structural ontology specification to automatically generate at 

20 least one file containing a search interface quality assurance checklist. 

59. The configured medium of claim 50, wherein the method uses ontology 
information extracted from the structural ontology specification to automatically generate at 
least one file containing a framework of a script for extracting product data from a text file. 

60. The configured medium of claim 50, wherein the method uses ontology 

25 information extracted from the structural ontology specification to automatically generate at 
least one file containing a framework of a script for loading product data into a product 
relational database. 

61 . The configured medium of claim 50, wherein the method uses ontology 
information extracted from the structural ontology specification to automatically generate at 

30 least one file containing a product data quality assurance script 

62. The configured medium of claim 50, wherein the method uses ontology 
information extracted from the structural ontology specification to automatically generate at 
least one configuration file for a graphical product data entry tool which accepts product data 
entered manually by a user and places the product data in a product relational database. 
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63. The configured medium of claim 50, wherein the method uses ontology 
information extracted from the structural ontology specification to automatically generate at 
least one file containing documentation which describes product data that is requested from a 
supplier regarding products to be offered in the electronic commerce marketplace. 
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